Enhancement: [ban-types] Split into default-less no-restricted-types and more targeted type ban rule(s)

[Josh Goldberg ✨]

Overview

Splitting out of #8700: ban-types has long been a kind of mirror to the core ESLint rule no-restricted-syntax. But, ban-types also comes with some default settings. That means the rule really has two areas of responsibility:

• Banning confusing built-in types
• Giving users the ability to ban types of their choosing

That dual-responsibility has led to the rule being more convoluted to configure than average. It's the only rule of ours right now that has to include an extendDefaults option.

typescript-eslint/packages/website/plugins/generated-rule-docs/insertions/insertNewRuleReferences.ts

Lines 22 to 28 in db4b5e0

 /** 
  * Rules that do funky things with their defaults and require special code 
  * rather than just JSON.stringify-ing their defaults blob 
  */ 
 const SPECIAL_CASE_DEFAULTS = new Map([ 
   ['ban-types', '[{ /* See below for default options */ }]'], 
 ]); 

Once #8977 is in, the defaults for ban-types will exclusively target the uppercase aliases of primitive types (Boolean, Number, ...) and the general Function and Object types. I think the v8 breaking changes are a good opportunity to further simplify the rule. Proposal: let's...

• Remove the remaining default options for ban-types, rename it to no-restricted-types (to mirror no-restricted-syntax), and remove it from recommended
• Add 1-3 new rule(s) in recommended that ban those previous default types
  • Starting proposal: a single no-uppercase-alias-types rule?

This would be a breaking change in that it would change the defaults for ban-types. Note that the stuff linted against by default in ban-types would still be linted against - just by different rule(s).