Cannot overwrite rule options from sharable config

[danny-andrews]

What version of ESLint are you using?
v2.9.0

What parser (default, Babel-ESLint, etc.) are you using?
babel-eslint

Please show your full configuration:
my eslint-es5.js:

{
  extends: ['airbnb-base/legacy'],
  rules: {
    'eqeqeq': 'error'
  }
}

Relevant part of airbnb-base/legacy.js:

{
  rules: {
    'eqeqeq': ['error', 'allow-null']
  }
}

What did you expect to happen?
I expected there to be a way to overwrite this 'allow-null' exception because I want to enforce eqeqeq at all times.

What actually happened? Please include the actual, raw output from ESLint.
I am still able to do bool == null.

[mysticatea]

Thank you for this issue.

I think this is an intentional behavior.
If this behavior is confusing, we should evaluate the value of the breaking change.

[ilyavolodin]

I think we should just update documentation to make it clear that configs are deep-merged.

[danny-andrews]

That doesn't solve these types of issues where you can't override behavior from extended configs. A non-breaking change we could make is to allow a predefined string to be passed as the second argument of a rule which tells eslint to use the rule defaults. Something like,

{
  "rules": {
    "eqeqeq": ["error", "use-defaults"]
  }
}

This would disable merging of rule options for this rule and use the defaults defined for this rule.

[alberto]

I think there should be an explicit default option for eqeqeq

[danny-andrews]

@alberto I feel like that is a bit of a band-aid solution, as this is an issue for other rules as well.

[alberto]

Then we should add options for those as well.

[danny-andrews]

Fair enough. Just seems error prone to have to add those options on a rule-by-rule basis.

[danny-andrews]

Any updates on this?

[platinumazure]

I'm not sure I agree with the logic that (in the OP's example) allow-null option should remain. I believe we should have configuration be all-or-nothing at the rule level-- if a rule is specified in derived config, it is assumed to be a full configuration that completely replaces the configuration specified in base config file.

Note that this still allows for the most common cases (derived config turns off rule enabled in base config, derived config turns on rule disabled in base config) to continue to work as they always have. In the case of derived config turning a rule on, the derived config must already specify a full and valid configuration.

In the case described by OP, we have an example of configuration being implicit in the derived configuration file. That strikes me as violating the principle of least surprise and I think we should change it, even if it's a breaking change.

[danny-andrews]

I agree with @platinumazure on this. I found it very surprising to inherit options from parent configs for rules I overrode in child configs. But at least if we were given a explicit default option, we could work around this. As it is, you can get stuck with certain rule options from parent configs and there is no way to override them.

[alberto]

@danny-andrews I added an option for eqeqeq. Have you found any other rule without an explicit default?

[alberto]

Closing in favor of #6361