Overrides of ignore patterns

[mysticatea]

From: eslint/eslintrc#20 (comment), #5410

The flat config should provide the way that end-users override the ignores setting of shareable configs and ESLint built-ins.

---

In .eslintignore, we can use negative patterns.

# .eslintignore
!/node_modules/my-package/
!.eslintrc.js

ESLint ignores /node_modules/* by default, but we can un-ignore it by such as the above setting.
Similarly, ESLint ignores dotfiles by default, but we can un-ignore it to lint .eslintrc.js-like config files.

---

In .eslintrc.*, the ignorePatterns setting is the same style as .eslintignore. Both end-user's configs and shareable configs can have the ignorePatterns setting. It let us override the settings of base configs.

# .eslintrc.yml
ignorePatterns:
  - "!/node_modules/my-package/"
  - "!.eslintrc.js"

---

I think we should consider it on the flat config system.

import baseConfig from "my-eslint-config"
export default [
  baseConfig, // when it has `ignores: ["/foo/*"]`
  {
    ignores: [
      "!/node_modules/my-package/", // un-ignore the built-in ignores
      "!/foo/bar"                   // un-ignore the base config's ignores
    ]
  }
]

---

Also, I think it's confusing with the following:

import baseConfig from "my-eslint-config"
export default [
  baseConfig, // when it has `ignores: ["/foo/*"]`
  {
    files: ["/**/*.js"],
    ignores: [
      "!/node_modules/my-package/", // 
      "!/foo/bar"                   // what happens?
    ]
  }
]

This is a topic that wasn't resolved in "Config File Simplification" RFC.

In eslint/rfcs#9 (comment) thread, I had tried to describe that the ignores setting has two meaning, then argued that it should be separated.

• If the files field exists, the ignores field is used for the adoption of the config array element and isn't merged for the ignore check. It's glob patterns as the RFC says. It corresponds to the files and excludedFiles of legacy configs.
• If the files field doesn't exist, the ignores field doesn't affect the adoption of the config array element and is merged for the ignore check. It's a list of gitignore-style patterns and supports negative patterns to override base configs. It corresponds to the ignorePatterns of legacy configs and .eslintignore.

[mysticatea]

My proposal is "clarifying the negative patterns in the ignores field." Because the RFC says the ignores field without the files field acts the same as .eslintignore and the ignorePatterns of eslintrc, and those support negative patterns, but it hasn't mentioned negative patterns.

The goal of this proposal is "allowing people to override upstream config about the ignores field" because I believe it's important for the config system that people can override shareable configs in their own config.

From "The eslint.config.js File" section

• files - Determines the glob file patterns that this configuration applies to. These patterns can be negated by prefixing them with !, which effectively mimics the behavior of excludedFiles in .eslintrc.
• ignores - Determines the files that should not be linted using ESLint. The files specified by this array of glob patterns are subtracted from the files specified in files. If there is no files key, then ignores acts the same as ignorePatterns in .eslintrc files; if there is a files key then ignores acts like excludedFiles in .eslintrc.

If the files field exists, does the ignores field support negative patterns? The excludedFiles of eslintrc doesn't support negative patterns, but it doesn't mention negative patterns. On the other hand, if the files field doesn't exist, it supports negative patterns as same as .eslintignore.

From "File Pattern Resolution" section

i. ESLint checks to see if there is one or more configs where the files pattern matches the file that was passed in and does not match the ignores pattern.

It sounds that it tests files with the files field and the ignores field separately rather than merges the ignores field into the files field as negative patterns. So probably the ignores field can support negative patterns similar to the files field.

ii. If a matching config is found, then the ignores pattern is tested against the filename. If it's a match, then the file is ignored. Otherwise, the file is linted.

How it works if there are multiple alone ignores fields?

My proposal is the same behavior as eslintrc; it merges all ignores fields and .eslintignore, then uses the merged patterns. It means the negative patterns in the ignores field can un-ignore the setting of shareable configs.

[
  { "ignores": ["**/.*"] }, // ignore dot files (assume come from a shareable config)
  { "ignores": ["!**/.special.js"] }, // un-ignore `.special.js`
]

However, I'm not sure how we should handle functions in the ignores field....

[nzakas]

We can take a look at this after we get the first prototype working. There is some complexity here because flat config is using globs while eslintrc uses ignore patterns, so I'm not sure matching eslintrc makes the most sense, but I think there's something we can do to allow excluding patterns from the ignores array.

[nzakas]

This was completed with some of the other work, most notably #16415 and #16416.