eslint: Bug: [new config system] `.eslintignore` doesn't work like `.gitignore`

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?

# .eslintignore

foo/
!bar.js

// eslint.config.js

module.exports = [{
    rules: {
        semi: "error"
    }
}];

// foo/bar.js

a

npx eslint foo/bar.js

What did you expect to happen?

0:0  warning  File ignored because of a matching ignore pattern. Use "--no-ignore" to override

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 the eslint.config.js config file, foo/bar.js would be ignored.

What actually happened?

  1:2  error  Missing semicolon  semi

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

Participation

I am willing to submit a pull request for this issue.

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).

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 21 (20 by maintainers)

Most upvoted comments

I know this is already closed out, but just wanted to add my thoughts.

Almost every project that uses ESLint also uses git (ESLint sort of acknowledges this by ignoring .git/** by default) and almost every git project has a .gitignore file.

There’s virtually no scenario where someone running ESLint on a project with a .gitignore wants ESLint to run over the ignored files. The developer will always want ESLint to ignore those files. So it seems that by removing this functionality, almost every project using ESLint will have to duplicate its ignore rules between .gitignore and the ESLint config. This is unfortunate because the two configs could easily become out of sync. People won’t like that so inevitably they will try to come up with ways to generate the ESLint ignore patterns from their .gitignore files.

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.

TomerAberbach on Oct 27, 2022

I’ve been looking more deeply into this, and here’s what I think is the best path forward:

I think that baseConfig and overrideConfig should both be relative to the basePath in the config array. I think it would be too confusing to try to make both of those relative to cwd. Because these are both API options (baseConfig isn’t used through the CLI at all), I think it’s fair to just explain in the docs that baseConfig and overrideConfig are essentially inserted into the array returned from eslint.config.js.
Given that, we would need to keep ignorePatterns as an option to FlatESLint so that --ignore-pattern can be added outside of overrideConfig. I do agree that --ignore-pattern would be expected to be relative to cwd.

What do you think?

nzakas on Sep 29, 2022

I think the patterns should have the same syntax and semantics as patterns in config ignores: [].

I agree. If we remove eslintignore then it makes sense for —ignore-pattern to use the same syntax as the config files.

Another question is - why we have this option in FlatESLint? It didn’t exist in the ESLint class, and --ignore-pattern does not translate to it.

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.

https://github.com/eslint/eslint/blob/8cc0bbe440dc5e6af6ef02f00d0514a40ca07c24/lib/cli-engine/cli-engine.js#L79

It seems safe to remove that option.

nzakas on Sep 14, 2022