Simplifying the configuration of plugins that replace ESLint's built-in rules

The version of ESLint you are using.

5.4.0

The problem you want to solve.

Currently when using babel-eslint and eslint-plugin-babel, one has to disable each of the original built-in rules and then enable the “fixed” replacement rules. For example:

{
  "rules": {
    "semi": 0,
    "babel/semi": 2
  }
}

However doing this when using a third-party style guide preset (such as eslint-config-airbnb) will cause the style guide’s own settings for the original rule to be lost, and for the babel/* rule to instead use the ESLint defaults.

My workaround for now is to import the rule configs from the style guide like so: https://github.com/neutrinojs/neutrino/blob/2b97e4b5edd8c15d2209054ffef90e0f84643adb/packages/airbnb/index.js#L2-L28

This hardcoded approach is not ideal since:

• if new rules are added, or import paths within eslint-config-airbnb change, then it will require manual changes. (There doesn’t appear to be an API that can be used to do so in a cleaner way - since getRules() only returns the rule’s defaults, not any configuration applied via extends.)
• it’s a lot of extra boilerplate for people to add, when ideally just enabling the eslint-plugin-babel plugin would be sufficient to adapt the ESLint builti-in rules for new JS syntax

Your take on the correct solution to problem.

It would be great if ESLint either:

• provided an API / config property that can be used by consumers of eslint-plugin-babel (and related plugins) to programmatically transpose/inherit the generated configuration from one rule to another, so we don’t have to use the current fragile approach
• allowed third-party plugins to declare that their rules are meant to overwrite in-built ESLint rules entirely. These replacement rules would just use the same name as the original rule - avoiding the need to transpose the config at all.

I tried searching for prior issues about this and found only #9192 - which appears to be about modifying just one rule, rather than interactions between two rules or allowing plugins to replace system/stock rules.

Many thanks 😃

[not-an-aardvark]

Hi, thanks for creating an issue. I agree that this is a problem, but I’m concerned that this solution would be messy in practice. For example, what would happen if the configuration for a third-party “replacement” rule is incompatible with the configuration for the original rule? Then if a shareable config tries to configure the original rule, it will result in a validation error.

[edmorley]

Sorry for the delayed reply.

@not-an-aardvark just to check I follow - you mean what happens if say the AirBnB preset configured the built-in semi rule with an option that babel/semi did not yet know about - meaning that the babel/semi custom implementation would end up being passed options that it could not handle?

This would presumably come about by ESLint adding a new backwards-compat feature (in a minor version release), and then AirBnb preset adding the option for that feature to their config.

However in such a case, this would be a breaking change for the AirBnB preset, since it would require them to bump their peer dependency on ESLint (even bumping minor versions of a peer dep is a breaking change) - meaning they would release the new AirBnB preset as a major version bump. This new major version wouldn’t be pulled into eg Neutrino (or someone’s local ESLint) config, since it wouldn’t be in-range.

Does that help? 😃