Respect .gitignore files by default?

Current situation

ESLint has several features around ignoring things, e.g.:

• .eslintignore
• some built-in rules like ignoring node_modules automatically (this changes over time, see e.g. 7.0.0 release notes)
• ignorePatterns in config files
• --ignore-path

Still, it’s currently quite hard to configure ignore rules correctly in a larger repo, without the setup being sort of duplicate/fragile. For example, in our monorepo, we have several subfolders, each with its own .gitignore file, and to replicate the correct ignoring behavior means duplicating ignore paths in the root .eslintignore file.

Previous discussions about .gitignore support

There have been issues around .gitignore support in the past, e.g.:

• Use .gitignore by default if no .eslintignore is found #5848
• Fallback to using .gitignore when .eslintignore doesn’t exist #12199

Some arguments against it were that ESLint should have its own mechanism independent on other systems, that it would add magic behavior, that it’s a breaking change or that you can usually find some workaround like building config.ignorePatterns in code.

I sort of agree with all of that, or at least see the point, but as a regular user of ripgrep or fd I have to say that I see no practical downside of respecting .gitignore by default – in fact, it’s a beautiful usability feature.

Worth an RFC?

I realize these things should go through the RFC process and I’m willing to do it but first I wanted to discuss this in an issue (that is not locked; otherwise, this is quite relevant: #12199).

What do you think about this? Am I missing some major downsides?

The biggest counter-argument, IMO, is that some files that were linted before would not be linted after this. To that, I’d say:

1. I’m not sure how common is linting e.g. dist/**.js files. My guess would be that it’s very rare but I acknowledge that it can happen.
2. These kinds of breaking changes are already happening, for example, with v6, someone could be linting subdir/node_modules which stopped working in v7.

It’s also possible to add this to ESLint in a non-breaking way, behind some new flag like --ignore-strategy=gitignore (this is different from --ignore-path, even if it supported multiple paths – #9794).

I generally think that the new behavior would be useful for most projects using ESLint (like the vast majority; “99%”) without many downsides. What do you think?

[mysticatea]

For a workaround for right now, I have released eslint-gitignore package as we can convert .gitignore files to our ignorePatterns option.

For example:

// .eslintrc.js
const { readGitignoreFiles } = require("eslint-gitignore")

module.exports = {
  // Your config.

  ignorePatterns: readGitignoreFiles({ cwd: __dirname })
};

---

My thoughts:

• It’s worth that we consider this feature because we have heard this request frequently.
• We can implement it by a utility package like eslint-gitignore in userland, but if ESLint reads it while traversing directories, it will improve performance. Because .gitignore files can be in subdirectories.
• Fallback to .gitignore is nice, but:
  • we should be able to override it by our config files (.eslintignore / .eslintrc.* / eslint.config.js). For example, I have often /test.* in .gitignore to play something, but I want to lint it.
  • we should support .eslintignore in subdirectories to be consistent. So both .gitignore and .eslintignore should behave samely.
  • Should we support other patterns of .gitignore? For example, $GIT_DIR/info/exclude, core.excludesFile setting of git, and ~/.gitignore? It will bring complex…
• I’m not a fan of new options for this because we have a lot of options.

[borekb]

already doable using a CLI flag

I don’t know how (--ignore-path cannot replicate the proposed behavior).

it’s a breaking change

I think it would be worth it but you’re right. Do you think it would be better to propose the behavior behind a new CLI flag to make it backwards compatible?