eslint.rules.customizations add rule options

[douglance]

Many eslint rules have additional configuration options that more finely tune how and when rules should be applied. Would it be possible to add those rules to the eslint.rules.customizations setting in VSCode?

It would be nice to have a workflow where my local development environment can have rules that are more strict than what is required by the project I'm working in. There are mistakes that I make consistently that I can prevent using specific rules that my entire team might not agree would make sense to enforce.

[dbaeumer]

Possible in general but requires some coding since it requires to override the rules. Currently we only tweak the severity after the fact (e.g. the rules are the same).

[edupsousa]

@dbaeumer may I take a chance on developing this feature? I made a first attempt at edupsousa@f1d74b3, but I will probably need some guidance on the best way to extend and parse configuration settings, writing documentation, and so on.

I tested this first attempt with ESLint version 8, and it looks like it's working fine. It reports and fixes using the override config, being the rule present or not in the original eslintrc. *. It also respects the settings on eslint.codeActionsOnSave.rules and eslint.rules.customizations.

If it's fine, I would like to open a draft pull request to keep working on and discussing this feature, ok?

@douglance I would like to point out that ESLint is moving in a different direction by deprecating the use of "personal" configuration (see eslint/rfcs#32), maybe this could make sense in a "project" oriented view, but I really like the idea of keeping the IDE flexible and enforcing project rules through build and integration process.

[dbaeumer]

@edupsousa can you please outline in detail how this would then look like in a settings file. What I don't want to do is to mirror all the possible ESLint rule settings in a VS Code settings file. We would need to maintain the config / JSON schema for it. In addition it would put us into a catchup game if things change.

[edupsousa]

@dbaeumer I agree, mirroring the ESLint config is a bad idea (and exactly what I naively did at first). After thinking a little bit about this issue I realized that its already possible to accomplish the rule overriding through the eslint.options setting:

@douglance to use stricter rules on your local environment you can create a custom ESLint config file, and then on .vscode/settings.json you can override the default ESLint config using the option overrideConfigFile for ESLint version 8, or configFile for previous versions:

{
  "eslint.options": {
    "overrideConfigFile": "custom-eslintrc.js"
  }
}

At first I thought that this option would complete ignore the ESLint config for the project, but looks like the override config file is merged on top of the project configuration.

Sample Gist:
https://gist.github.com/edupsousa/a3c01c38185018ec55f21df8cc22d187

[dbaeumer]

@edupsousa that is actually a good (and right) solution. I will close the issue although it requires ESLint 8 which we would require of the eslint.rules.customizations setting as well.

[viT-1]

@edupsousa

Sample Gist: https://gist.github.com/edupsousa/a3c01c38185018ec55f21df8cc22d187

Can we override project (remote) rules with local (drive) eslintrc.json file in flat config format?