Vscode-eslint: Allow omitting specific rules from fix

[Jamesernator]

I am aware #208 was already closed, however since then a specific API for filtering rules from being fixed was added to CLIEngine https://eslint.org/docs/developer-guide/nodejs-api#cliengine .

One of the pain points with the solution in #208 is that the no-autofix plugin requires adding it into every project specifically and only supports the builtin rules.

I'd like to propose again supporting an eslint.rulesToDisableWhileFixing option that takes a list of options. The vscode-eslint could then use this list like so:

newOptions.fix = function({ ruleId }) {
  if (!pluginOptions.rulesToDisableWhileFixing) {
    return true;
  }
  return !pluginOptions.rulesToDisableWhileFixing.includes(ruleId);
}

[Jamesernator]

Alternatively as an even more flexible option it might be a possibility to treat eslint.options.fix as a function body if it happens to be a string e.g.:

const fix = typeof newOptions.fix === 'string'
  ? new Function('rule', newOptions.fix)
  : newOptions.fix;

Then in settings.json one could do:

{
  "eslint.options": {
    "fix": "return !['prefer-const', '@typescript-eslint/no-unnecessary-type-assertion'].includes(rule.ruleId);"
  }
}

Or maybe just eval the 'fix' option to get a function:

{
  "eslint.options": {
    "fix": "({ ruleId }) => !['prefer-const', '@typescript-eslint/no-unnecessary-type-assertion'].includes(ruleId)'"
  }
}

[revelt]

PS. Atom has it already so VSCode should be able to implement it as well:

—https://atom.io/packages/linter-eslint

[dbaeumer]

Good PR opportunity.

However I am against eval since this will result in a security problem.

[revelt]

to add 2p., it's essential that we skip rules on code editor level only. When I upload the code to the CI (GitLab's or whatever), I do want the code to be fixed.

In practice, while developing, I want to exclude ESLint rules that catch t.only() isolated unit tests from auto-fixing. Otherwise, when I save, .only would get removed and unit test isolation would not work at all. But on CI release builds, I do want the autofix — if t.only() spills into production suddenly only one unit test will be checked, instead of the whole test suite. Bugs might pass through into production release.

It's very important to be able to disable autofixing at VSCode level only, not on .eslint.rc or anywhere where "normal", CI-driven ESLint would understand.

PS. Until it's implemented I can't use VSCode...

[branflaker]

Another idea for a possible implementation. Instead of specifying rules to disable for autofixing, how about specifying a path to a separate ESLint config? You get a lot more control over how you want your autofixes applied then (more than just disabling specific rules). Something like:
```
{
"eslint.options": { "autofixConfigFile": "C:/mydirectory/.eslintrc.json" }
}