Implement "eslint.rules.customizations" - Allow users to override rule severity from VS Code settings

[jamesorlakin]

This hopefully closes #468 based on the discussions in #561.

This PR implements a new extension option, allowing diagnostics reported by the ESLint extension to be overridden by user settings within VS Code. The main usecase is to allow linting errors to be visually different to actual typing/compilation problems based on personal preference, especially if adjusting the ESLint configuration itself is difficult (e.g. it's prepackaged, StandardJS, etc) or there's a fear of committing these customizations accidentally.

For example, the playground environment in this PR:

The eqeqeq rule is an error in ESLint parlance, but the * override forces it to be a nicer yellow warning. I personally prefer this representation of all linting warnings.

---

All comments are welcome.

[dbaeumer]

Thanks a lot for starting working on this.

I saw that you already implemented having more than one customization. Although I started this settings wise as a literal we should convert that to an array to be able to specify order. For example:

[
    { rule: "no-extra-semi", severity: "info" },
    { rule: "*", severity: "warn" }
]

We could then also use the ! to negate rules (like in .gitignore files

Does that make sense.

[jamesorlakin]

Aah ok, that's very granular. I'll admit I don't really see a usecase for ! negation, unless that implies we implement wildcard matching? I can understand why Git does that but I'm struggling a little for ESLint rule names.

So If I'm understanding it right: something like this, where ! means ignore the rule?

[
    { rule: "no-*", severity: "warn" },
    { rule: "*", severity: "info" },
    { rule: "!radix" }
]

In such a case I feel having a severity of 'ignore' would be clearer and wouldn't need the ! symbol.

[dbaeumer]

{ rule: "!radix" } would render as defined in the eslintrc.json. How would ignore be interpreted when used as a severity.

[jamesorlakin]

Aah, I didn't fully understand what "negating" a rule meant in this context. In retrospect I think it means to 'ignore' an override (i.e. rule 1 is * to make everything warnings, rule 2 is !no-semicolon and means let that rule be treated based on the ESLint config) if that's right?

Initially I was thinking you meant add the ability to filter out rules, which I guess is possible as well but I don't see anyone having a usecase for that.

[dbaeumer]

rule 2 is !no-semicolon and means let that rule be treated based on the ESLint config

Absolutely corret.

[JoshuaKGoldberg]

Ping @dbaeumer @jamesorlakin, is this still something either of you are working on? This is a big pain point for me (& others) so I'd be very interested in picking up this work if neither of you have time?

[dbaeumer]

I am not actively working on this right now.

[jamesorlakin]

Hi @JoshuaKGoldberg, this is something I admit I've forgotten as my work has largely moved to Java nowadays! Sorry about that. You're welcome to continue, or I can have a look at continuing during the next weekend. It's the 'negating' logic that was left to do, though I assume it doesn't need to be that advanced.

[JoshuaKGoldberg]

Continued in #1164 🤗

[dbaeumer]

@JoshuaKGoldberg thanks for picking this up again!

[jamesorlakin]

Closing in favour of #1164. Thanks ever so much @JoshuaKGoldberg!