Create a "strict" config between "recommended-requiring-type-checking" and "all"

[JoshuaKGoldberg]

Overview

Moving discussion out of https://twitter.com/JoshuaKGoldberg/status/1500610010576994306: it seems to me that there are at least two classifications of lint users we should target:

• Starter: most users at least to begin with. These users likely don't have a "power user" w.r.t. typescript-eslint on their project and thus don't want particularly strict, annoying options enabled. They should be given rules that are clearly demonstrate linting value.
  • Lint configuration target today: recommended or recommend-requiring-type-checking
• Power: users who have seen the power of typed linting and want to get the most out of it. They want our somewhat-opinionated strict configs that enforce best practices too -- and can handle the sometimes aggressive lint errors as a result.
  • Lint configuration target today: missing

I propose we create a plugin:@typescript-eslint/strict config that adds a suite of best practice rules on top of recommended-requiring-type-checking.

[bradzacher]

The recommended set should be that set of best-practice rules.
Back when it was implemented it was an opinionated set, but each major we've trimmed away the stylistic rules.

What rules do you propose we remove for the "strict" set?

[JoshuaKGoldberg]

but each major we've trimmed away the stylistic rules

Exactly: those are the ones I'm proposing be added to the "strict" set. Or, maybe "opinionated" would be another good -perhaps better- name for it?

From a quick pass over https://typescript-eslint.io/rules/#supported-rules...

• array-type
• class-literal-property-style
• consistent-indexed-object-style
• consistent-type-assertions
• consistent-type-definitions
• no-confusing-non-null-assertion
• no-confusing-non-void-expression
• no-dynamic-delete

...and so on. My exclusion criteria was pretty much anything related to formatting or that you wouldn't want to enable 80% of the time. Perhaps that's a good criteria for the rulesets?

• Recommended: Desirable roughly >95% of the time
• Strict: Desirable roughly >80% of the time
• All (i.e. criteria for inclusion in core): Desirable roughly >67% of the time

[bradzacher]

oh sorry - I misunderstood your intention!
I thought your intention was that strict would be a subset of recommended, but your intention is that strict is a superset.

[JoshuaKGoldberg]

Reference PR here with the list of rules I think would be reasonable to try starting with: #4706

A couple of notes:

• They're all set to warnings right now. My thought was that if they're severe and functionality-focused (rather than stylistic) enough to be an error, we'd probably want them in a recommended ruleset.
• In my mind, the "strict" name nicely parallels TypeScript's strict setting by implying we might intentionally modify it in any minor version.

[stefee]

Does the type definition rule default to “interface” or “type”?

[JoshuaKGoldberg]

@stefee great question, but we generally ask that you don't post unrelated comments or questions on existing issues or PRs -- especially those that are already closed. It's hard for us to keep track of them and they're not very searchable for other users.

Would you mind filing a new issue reporting that our docs are missing saying what the default is on https://typescript-eslint.io/rules/consistent-type-definitions?

(hint: check https://github.com/typescript-eslint/typescript-eslint/blob/4a500b2/packages/eslint-plugin/src/rules/consistent-type-definitions.ts; it looks like there isn't a default -> you have to provide it yourself)