Cannot overwrite rule options from sharable config
See original GitHub issueWhat 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
.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:12 (12 by maintainers)
Top Results From Across the Web
Shareable Configs - ESLint - Pluggable JavaScript Linter
You can override settings from the shareable config by adding them directly into your .eslintrc file. Sharing Multiple Configs. It's possible to share...
Read more >Override rules from eslint-plugin-prettier - Stack Overflow
I have tried to override all rules found in eslint-prettier-config, but nothing worked and I don't want to keep using // eslint-disable-next- ...
Read more >Overriding or Reverting a Security Policy Rule
The settings you can override are a subset of the full set (the following table lists the subset for security rules). For details...
Read more >Configuring enhanced health rules for an environment
You can't configure enhanced health to ignore other HTTP errors in ... Do not delete it—add a Rules section into the same ConfigDocument...
Read more >Add rules to a shared mailbox - Microsoft Support
In Outlook 2016 access File > Account Settings > Account Settings… · On the Email tab select New… · Select Next to proceed....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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.
I think there should be an explicit default option for
eqeqeq