Extending rule options in derived configs?

This comes up fairly frequently: Someone extends a shareable config or plugin config which might use no-restricted-syntax or similar to lint certain patterns. A user may wish to alter the list of linted patterns to add one more pattern; however, right now, this means copying the whole list from the shareable config or plugin config, which basically defeats the purpose of using a shareable config in the first place.

I wanted to get the ball rolling on discussing how we might address this with one simple, incomplete, likely flawed proposal. I’m hoping that we can come up with something good after a spirited discussion.

My proposal:

• Augment new-style rule support in core to allow an extendConfiguration method (in line with meta property and create method).
• The extendConfiguration method takes two arguments: old options, and new options (in both cases with severities removed). It should return an options object that (ideally) contains a merging of the two sets of options, in whatever way makes sense for the rule in question.
• When resolving configurations, ESLint core would load the rule, look for an extendConfiguration method, and call it with old and new options if it is present. If not, ESLint core will simply override with the new options, matching current behavior.

One possible challenge I am already seeing is that this requires CLIEngine to load and work with rules, instead of Linter. This may not be a problem if schema validation is also being handled by CLIEngine, but I can’t remember if it is. I’m sure there are more issues with what I have proposed as well. But let’s see if we can come up with something workable and get this sorted!

[ilyavolodin]

I think this is a problem worth solving, but I’m against solving it with adding a first (optional) argument. We state everywhere in our documentation that the first argument of the configuration array is always severity of the error. I think it would be very confusing if we were to break that promise. What if we just split configuration into separate object?

{
  "rules": {
    "semi": ["never"],
    ....
    "inherit": {
      "no-restricted-syntax": ["error", "ForOfStatement"],
      ...
    }
}

This will allow for much clearer backwards compatibility. Inherit could also be a top level node if you don’t like nesting it under rules, although I would call it inheritedRules in that case.

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