Support directive comment groups

The version of ESLint you are using. Latest

The problem you want to solve. We run eslint once on our source code and again on the build output, with different config and plugins.

Any directive comments get picked up by both the source lint and the build lint. We can disable processing directive comments completely on the build lint, but it would be useful for comments to target either the source/build lint. Some of the rules we have on the build lint have false positives so it would be useful to be able to add /* eslint-disable-line custom-rule */ comments to disable them.

Your take on the correct solution to problem. Add the ability to assign directive comments to groups, and specify the group that should be used when running eslint. Any comments that are not part of the provided group are ignored. The group would default to default and it could be a non-breaking change.

Are you willing to submit a pull request to implement this change? Yes. I opened a draft (https://github.com/eslint/eslint/pull/13471) and it would be great to get some feedback before I continue and figure out how to add some tests.

[btmills]

Disable comments are a sometimes-necessary escape valve, and while conditional disable comments are a neat idea, I don’t see us adding features to disable comments to encourage people to reach for them as anything more than a last resort. If there were some use case that couldn’t be achieved another way, that might change things, but in your case you have a couple of less invasive options.

Another one I thought of since my earlier comment: if your codebase is in TypeScript, you should be able to make your rule type-aware so that it only reports e.g. .find() on instances of Array, which would fix the false positive issue altogether.

If this is still something you’d like to see implemented, we can leave the issue open to see if anyone else on the team has ideas for other use cases and want to include this.

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.