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

[TomerAberbach]

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.

[nzakas]

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

1. 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.
2. 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?