Overrides should support AST selectors for whitelisting nodes from specific rules

The version of ESLint you are using:
v5.11.0 (Current, as of this writing)

The problem you want to solve:
I’d like to configure my .eslintrc.json file to exempt certain constructs from arbitrary rules, possibly with further restrictions based on pathname. Something like this:

// Exempt cuddled `try/catch` blocks from Stroustrup brace-style:
"overrides": [{
	"selectors": {
		"CatchClause *": "never"
	},
	"rules": {
		"brace-style": "off"
	}
}]

Sadly, the only use for selectors in configs (by default) is for the no-restricted-syntax rule:

What can selectors be used for?

If you’re writing custom ESLint rules, you might be interested in using selectors to examine specific parts of the AST. If you’re configuring ESLint for your codebase, you might be interested in restricting particular syntax patterns with selectors.

This isn’t what I want to do. Nor do I want to write a custom ESLint rule, only to refine the scope of an existing one. I also don’t want to publish a plugin (or compose one) for setting an exception which might be site/project-specific, or simply a tweak that’s too arbitrary to justify or explain if it were a plugin/rule:

"devDependencies": {
	"eslint-config-no-useless-concat-except-in-expressions-with-only-two-binary-operators":
	"^0.1.0"
}

Your take on the correct solution to problem:
Add support for a selectors property in override objects, and/or the top-level configuration file. Matching logic could be further refined by additional logical operators (e.g, any, all, etc).

Are you willing to submit a pull request to implement this change?
If a maintainer gives me the green light, then by all means.

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

[nzakas]

Sorry, I see I didn’t explain myself well. Currently, there is no guarantee that specific rules will trigger a warning for specific AST patterns. The warnings that rules produce may change over time and the rules themselves may change which patterns they look for to trigger a specific warning. That’s why we don’t recommend using subclassing to extend core rules.

As I mentioned, you are more than welcome to submit an RFC if you feel strongly that your idea will be of benefit to the community. It’s possible I’m not fully understanding your suggestion and seeing a complete design would make your case more concrete.

Alternatively, you can open a new issue requesting a change to the brace-style rule that will serve your purpose.

On Thu, Jan 3, 2019 at 2:32 AM John Gardner [e-mail] wrote:

because you’ll constantly be caught trying to identify all possible patterns

That doesn’t make any sense. If all I care about is exempting a specific construct from being checked by a specific rule, why should I be concerned with unrelated AST selectors?

I really don’t want to go through the effort of using a third-party tool and excessive complexity over something admittedly arbitrary, and if it’s possible to blacklist arbitrary constructs https://eslint.org/docs/rules/no-restricted-syntax using AST selectors, then it should theoretically be possible to use the same mechanism to restrict or whitelist certain syntax from being detected by rules.

Having such a limited configuration use for AST selectors is a waste of a perfectly good feature, IMHO.

Failing everything else, please extend your brace-style rule to be more permissive. There’s no such thing as “the one true brace-style”.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eslint/eslint/issues/11207#issuecomment-451106226, or mute the thread https://github.com/notifications/unsubscribe-auth/AACWkrOtw2s8ajiE6wYKClNJoxBFU_-Dks5u_dw2gaJpZM4Zg9nR .

–

---

Nicholas C. Zakas @slicknet

Author, Principles of Object-Oriented JavaScript http://amzn.to/29Pmfrm Author, Understanding ECMAScript 6 http://amzn.to/29K1mIy