Respect up-the-tree .gitignore files

[alecmev]

I have a .gitignore in my ~ with the following contents:

.scratch/

This allows me to plop .scratch directories all over the place and put not-for-remote stuff there like personal notes, half-baked code snippets, etc. Knip, unfortunately, doesn't look at ~/.gitignore and reports code files in .scratch directories as unused.

I don't want to add .scratch to the repo .gitignore because it has nothing to do with the project. I don't want to store these files outside of the repo because I want to keep them close to the packages they're related to.

[webpro]

Does something like npm do the same eg when publishing?

[alecmev]

Doesn't look like it, unfortunately:

https://stackoverflow.com/q/12534699/242684
semantic-release-action/typescript#10 (comment)

Though I wouldn't treat npm's choices as gospel 😅

[alecmev]

To frame this a little bit differently, how else could I tell Knip to ignore **/.scratch/** without polluting the configuration?

[webpro]

I'm not against the feature per se, but I also don't want unexpected results. What might be a feature to you, could be a hard-to-track and tricky-to-overcome issue to someone else.

So if other tools use it as well it's common/expected behavior.

To frame this a little bit differently, how else could I tell Knip to ignore **/.scratch/** without polluting the configuration?

You can use ignore at the root config with this pattern. If you don't fancy that you could perhaps use a knip.ts and make it more DRY.

[alecmev]

I'm struggling to find examples. Prettier doesn't respect .gitignore, nor does ESLint. Biome, however, does (at least intends to). Outside of JavaScript, RipGrep does too, and fd. Can you maybe suggest some more projects to take a look at?

I'm not against the feature per se, but I also don't want unexpected results. What might be a feature to you, could be a hard-to-track and tricky-to-overcome issue to someone else.

On the one hand, I agree, changes like this require justification. On the other hand, Git is the common denominator here. If a file ultimately isn't committed, does it make sense to ever take it into consideration?

[TheKnarf]

It should probably just follow whatever git check-ignore does?