fix: Ignore transient tap test directories

[rotu]

Running tests causes a lot of file churn. Although (usually) ephemeral, these files cause high CPU usage and can make developer tools difficult to use. These files also make linting fail.

Now the files will be ignored by git and by eslint.

References

Fixes #348
Fixes #359

[wraithgar]

I'll let @lukekarrys weigh in here since it's surprising to me coming in fresh on this that we don't have anything in here already.

[lukekarrys]

@rotu the current pattern is to put these paths in lib/content/gitignore and leave ignorePaths as a config to be set by consumers. can you make that change? apologies that this is not discoverable! 🙇🏼

[rotu]

No worries. I can add the breadcrumbs that would have retroactively helped me. The lib/content/gitignore file is clearly a template of some sort. What instantiates this template?

EDIT: nvm found it: https://github.com/npm/template-oss/blob/2a5e18677f6de45d903b7d06ec7780c7d31b6963/lib/util/template.js

[rotu]

Also, any reason why allowPaths and distPaths are inlined in this file but ignorePaths is not?

[wraithgar]

CI is goofy cause of a new timers/promises require, don't worry about it.

[rotu]

CI is goofy cause of a new timers/promises require, don't worry about it.

That only explains the node@14 errors.

This is curious to me: https://github.com/npm/template-oss/actions/runs/6103503295/job/16623491287?pr=350

Run npm i --prefer-online --no-fund --no-audit -g npm@latest
npm ERR! code EBADENGINE
npm ERR! engine Unsupported engine
npm ERR! engine Not compatible with your version of node/npm: npm@10.0.0
npm ERR! notsup Not compatible with your version of node/npm: npm@10.0.0
npm ERR! notsup Required: {"node":"^18.17.0 || >=20.5.0"}
npm ERR! notsup Actual: {"npm":"8.6.0","node":"v18.0.0"}

I don't expect this since:

Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.

[wraithgar]

npm has a special check it does if it detects you are installing npm globally, strict engines checks are done then. This started in npm 7

cf npm/cli#3731

[wraithgar]

This is how we've been fixing the ci for packages that didn't get an engines bump to match npm 10 npm/read-package-json#190

[rotu]

That's a major wtf! There should definitely more specific error, especially since the error is the exact same one packages can no longer enforce:
https://docs.npmjs.com/cli/v6/configuring-npm/package-json?v=true#enginestrict

[wraithgar]

Yeah after many rfc calls it was decided that package maintainers should not be able to specify things like that, only the consumers.

npm is a special snowflake because it IS what you use to install packages, so if it ends up installing a version that doesn't work in your current node, you can't run it to fix the problem.

[rotu]

Back to a draft to figure out interaction with tapjs/tapjs@a5dc854

[wraithgar]

sigh I'm gonna miss using git status to find where TAP_SAVE_FIXTURE left its stuff for a given test but this is the right choice.

[wraithgar]

@rotu I can't land this cause of conflicts, and they're the kind I can't even resolve in the GitHub ui :/

[lukekarrys]

@rotu can you try fetching the latest origin/main and then running git rebase origin/main on your feature branch? That's what I normally do when conflicts get in a weird state.

[wraithgar]

Rebased in #364 once @lukekarrys approves it'll auto merge.

[wraithgar]

Sorry about the merge conflicts @rotu, we got there in the end. #364 landed.

Thanks again for all the help.

[rotu]

Oops! I was going to do that, but thank you for the favor, @wraithgar!