New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: [new config system] .eslintignore
doesn't work like .gitignore
#16264
Comments
Unfortunately this is not so easy. Because ignores in Note: Originally the flat config RFC specified that So I think we have these possible paths forward:
I'm pretty burned out from all this config work, so if anyone else wants to take a look, I'd appreciate it. |
I don't think it's viable for the two different styles to work together, because each style has its own rules about how a list of patterns as a whole should work. I think we should decide between the .gitignore style (with the .gitignore interpretation of individual patterns and the .gitignore rules about how lists of patterns work) and the other style (with globs and ESLint-specific rules about how lists of patterns work).
If we decide to support .gitignore-style, then it seems much better to use an existing library like the
If it comes down to these two choices, I'm in favor of dropping I think the first question should be - do we want to support .gitignore-style? Pros:
Cons:
|
I remembered last night why I didn’t use the ignore package. There were two issues:
As a note: the other examples you mentioned don’t all implement the gitignore spec. npmignore definitely doesn’t as it uses minimatch. I think there is a strong argument to eliminate eslintignore for flat config. Early on, users asked us to put ignores into the config file (eslintrc) so they could have all of their configuration in one spot. Once we did that, we probably could have eliminated eslintignore. Also, with flat config, people can create an instance of |
@btmills could use your input here. |
If there's no good way to have And as @nzakas pointed out above, if someone still wants to be able to reuse their |
Okay, it sounds like we are in agreement to remove eslintignore support and see how things go. |
The same applies to Also the same for |
I agree. If we remove eslintignore then it makes sense for —ignore-pattern to use the same syntax as the config files.
That’s interesting. I think this comes from CLIEngine. The ESLint class is just a wrapper around CLIEngine, and it was difficult trying to reconcile the two files. I probably just copied it at some point and didn’t stop to verify. eslint/lib/cli-engine/cli-engine.js Line 79 in 8cc0bbe
It seems safe to remove that option. |
@nzakas I could take this if you haven't already started working on it. |
@mdjermanovic go for it! |
One question before removing I believe that patterns coming from |
Yes, that was the intent. But it looks like in eslintrc this option was removed rather than handled separately, which is why I think things got weird when I was trying to get flat config in. We should be mirroring what eslintrc did.
Agreed.
There is a distinction here: For |
By
I think the expected behavior would be that patterns in |
After thinking about this a bit, assuming we keep
|
I've been looking more deeply into this, and here's what I think is the best path forward:
What do you think? |
👍 I'd guess that specifying files/ignores isn't a common use case for these configs, so it seems better to simplify this greatly by not adjusting paths.
👍 I assumed we might want to keep |
I'm working on this. |
@nzakas FWIW I made a complete implementation of the gitignore spec: https://github.com/jedwards1211/gitignore-fs. |
@jedwards1211 Thanks for the option but we are removing gitignore-style ignores. |
I know this is already closed out, but just wanted to add my thoughts. Almost every project that uses ESLint also uses There's virtually no scenario where someone running ESLint on a project with a If that's where we'd likely end up, then I wonder why not bake this functionality into ESLint to avoid N different userland solutions for the problem? I get that it's a complex issue, but it seems like scoping it out of ESLint would just push the problem into userland, which doesn't seem desirable. |
stupid question: why are we even bothering to mimic gitignore... isn't things like micromatch etc better syntax? (spoiler: i think so)
can just use some logic like "convert found ignore file to micromatch globs, then merge as winning globs" |
Environment
Node version: v16.14.0
npm version: v8.3.1
Local ESLint version: v8.23.0 (Currently used)
Global ESLint version: Not found
Operating System: win32 10.0.19044
What parser are you using?
Default (Espree)
What did you do?
What did you expect to happen?
Per the .gitignore specification,
foo/bar.js
should be ignored because it is not possible to re-include a file if a parent directory of that file is excluded. With an equivalent.eslintrc.js
config file in place of theeslint.config.js
config file,foo/bar.js
would be ignored.What actually happened?
Participation
Additional comments
There may be other differences between the .gitignore spec and our custom interpretation of the patterns, so it might be better to keep using the
ignore
library (assuming that.eslintignore
should still behave like.gitignore
).The text was updated successfully, but these errors were encountered: