Enhancement: [ban-types] Split into default-less no-restricted-types and more targeted type ban rule(s) #8978
Labels
breaking change
This change will require a new major version to be released
package: eslint-plugin
Issues related to @typescript-eslint/eslint-plugin
triage
Waiting for maintainers to take a look
Milestone
Overview
Splitting out of #8700:
ban-types
has long been a kind of mirror to the core ESLint ruleno-restricted-syntax
. But,ban-types
also comes with some default settings. That means the rule really has two areas of responsibility: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
Once #8977 is in, the defaults for
ban-types
will exclusively target the uppercase aliases of primitive types (Boolean
,Number
, ...) and the generalFunction
andObject
types. I think the v8 breaking changes are a good opportunity to further simplify the rule. Proposal: let's...ban-types
, rename it tono-restricted-types
(to mirrorno-restricted-syntax
), and remove it fromrecommended
recommended
that ban those previous default typesno-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 inban-types
would still be linted against - just by different rule(s).The text was updated successfully, but these errors were encountered: