I don't like this name 😦 but couldn't think of one I really do like...no-primitive-class-wrappers?no-class-wrapper-types? So wordy, but I also like ending with-types... Someone please help 🙏

TL;DRban-bad-built-in-class-types or even justban-bad-class-types

wordy? you must hateuse-unknown-in-catch-callback-variable 😆

I guess the commonalities in this rule are, for type X flagged by the rule

• X is built-in ("built-in", "intrinsic")
• the types means "something which has X.prototype in its prototype chain". (gives us "class-type"/"object-type"/"prototype-type"/etc) <-- This makes the rule hard to name
• that type is bad for some reason, but not necessarily the same reason...
  • in the case ofBigInt,Boolean,Number,String,Symbol, because they refer to the boxed primitive, but the unboxed primitive is also assignable
  • Object, because it's terrible; any primitive is assignable, similar to previous
  • Function, because it's unsound <-- This makes the rule hard to name
  • Technically we could argue all of these are unsound, butFunction is really a difference in kind compared to the others, so it's hard to justify using "unsound"/"unsafe" in the name
• X is uppercase -technically true but not really the point 😄

So that would lead me to a rough template of{no/ban}-bad-{built-in/intrinsic}-{instance/prototype/class/object}-types of which my tentative favorite isban-bad-built-in-class-types.

I'm not a fan of "wrapper" sinceObject andFunction aren't wrappers. And same problem arises with using the word "primitive". IfFunction weren't part of the rule though I thinkno-{boxed/wrapped}-primitive-type would work nicely 🤷

👋 What aboutno-ts-wrapper-types ?

Pro: These types are all defined by TypeScript itself, and the list of banned types not only includes primitive wrappers, but also wrappers forobject and a wide, any-ishfunction which are technically not primitivesper MDN. The name indicates it's related to a TypeScript feature itself likeban-ts-comment does.

Con: Might be a little more confusing / need further explanation in the docs.

wordy? you must hateuse-unknown-in-catch-callback-variable 😆

Haha, yes, I do! And now I'm realizing maybe we could have called it justuse-unknown-in-catch-callback. Ugh.

Long rule names make for less readable/pronouncable editor popups & CLI complaints. They're actively (mildly) worse for users.

Some more suggestions from across the internet:

• no-boxed-primitive-types (@molisani)
• no-class-wraps (@bumpylumps)
• no-class-wrapper-types (@bennycode)
• no-object-instances-as-types (@gangsthub)
• no-primitive-constructors (@niklas-wortmann)
• no-primitive-wrappers (@davidlj95)
• no-primordial-constructors (@boneskull)
• no-upper-case-primitive-type (@bradzacher)
• no-wrapper-types (@jakebailey)
• no-wrapper-types orno-primitive-wrapper-types (@sandersn)
• prefer-lowercase-intrinsic-type orprefer-intrinsic-type (@Josh-Cena)
• prefer-primitive-type (-thingy) (@the-ult)

Some general thoughts...

• "Primitive"would be something nice to include in there, but as@Josh-Cena pointed out,object isn't a primitive and so that's inaccurate
• MovingFunction bans into a separate rule (no-unsafe-call: ban calling Function #9108 (comment)) would help narrow down the naming
  • It'd be nice for naming to also move outObject bans into its own rule so we could then use"primitive" after all, but I don't know of any justifications on that one 😕
• It's hard to justify using a term that isn't in common usage already. Words like"boxed" and"primordial" might (previously or presently) be good descriptors, but if they don't match MDN docs or common StackOverflow nomenclature, users will have a hard time with them
• We don't generally put abbreviations in rule names anymore. It's hard enough for users to understand lint rules, let alone have to remember random abbreviations in there too.
• I think it'd be nice to include some indication in the name that it's abouttypes /type annotations, not generally using those things. E.g. ending with-types. That'd help disambiguate from other rules that do banusage of some types (e.g.no-unsafe-* foranys).

That leaves a few finalists IMO:

• no-class-wrapper-types
• no-intrinsic-wrapper-types
• no-intrinsic-class-wrapper-types
• no-primitive-class-wrapper-types
• prefer-lowercase-intrinsic-types:if we split outFunction into its own rule, since lower-casefunction isn't a type

I'll continue to ruminate...

I personally find the mention of "class" to be very odd, especially given pages likehttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number andhttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/Number do not contain that string.

I can see how the term "class" could be confusing as it could be associated with limiting the behaviour in a realclass. While reading through the MDN docs, I came across this:

When properties are accessed on primitives, JavaScriptauto-boxes the value into awrapper object and accesses the property on that object instead. For example, "foo".includes("f") implicitly creates aStringwrapper object and callsString.prototype.includes() on that object. Thisauto-boxing behavior is not observable in JavaScript code but is a good mental model of various behaviors

Source:https://developer.mozilla.org/en-US/docs/Glossary/Primitive

Stating the above, would these names be acceptable?

• no-wrapper-object-types
• no-auto-boxing-types

@kirkwaiblinger what do you mean aboutObject not being a wrapper?

Oh, well, I think I meant the Object type doesn't conceptually refer to a wrapper around a primitive, though as you pointed out (and I wasn't aware) thatis a subset of its possible uses. So, feel free to disregard my comment on that; my mind has been changed 🙂

I likeno-wrapper-object-types a lot!"Wrapper" might be a bit general on its own, but the built-in upper-case types are the only ones I can think of that that jump to mind as"wrapper object types". Nice@bennycode!

Renaming now, but if anybody doesn't like this then please do continue the conversation. 🙁

Update: following#9102 (comment), I split out ano-unsafe-function-type.@Josh-Cena makes a good point that the function type isn't a wrapper.

That leaves the question of whether theno-wrapper-object-types name is ok to includeObject. I.e. being ok with what@kirkwaiblinger mentioned: that it's not technically a wrapper itself. I'm in favor of allowing this: more convenience at the cost ofslightly less pedantically correct rule name. But I could be convinced otherwise if we have a good rule name alternative and/or have justification to moveObject into its own rule (do we?).

TL;DRban-bad-built-in-class-types or even justban-bad-class-types

wordy? you must hateuse-unknown-in-catch-callback-variable 😆

I guess the commonalities in this rule are, for type X flagged by the rule

• X is built-in ("built-in", "intrinsic")
• the types means "something which has X.prototype in its prototype chain". (gives us "class-type"/"object-type"/"prototype-type"/etc) <-- This makes the rule hard to name
• that type is bad for some reason, but not necessarily the same reason...
  • in the case ofBigInt,Boolean,Number,String,Symbol, because they refer to the boxed primitive, but the unboxed primitive is also assignable
  • Object, because it's terrible; any primitive is assignable, similar to previous
  • Function, because it's unsound <-- This makes the rule hard to name
  • Technically we could argue all of these are unsound, butFunction is really a difference in kind compared to the others, so it's hard to justify using "unsound"/"unsafe" in the name
• X is uppercase -technically true but not really the point 😄

So that would lead me to a rough template of{no/ban}-bad-{built-in/intrinsic}-{instance/prototype/class/object}-types of which my tentative favorite isban-bad-built-in-class-types.

I'm not a fan of "wrapper" sinceObject andFunction aren't wrappers. And same problem arises with using the word "primitive". IfFunction weren't part of the rule though I thinkno-{boxed/wrapped}-primitive-type would work nicely 🤷

Why are we deprecating the rule?
There's still value in the rule - just that the default config can be empty now.

People use this rule all the time to ban various types across their codebase. It's the only way to reliably target type names only without hitting value names.

@bradzacher because it's essentially being renamed tono-restricted-types, with the default values split into more targeted rules. I'll update the deprecation notice to make it more clear.

Given this is a major - should we just remove the old rule name entirely?
Is there a benefit to keeping it if we're adding the new rules to recommended and the old rule should almost be a 1:1 name swap in config?

I was thinking this is a pretty user-known rule so leaving it in would help with migration. The name swap might be 1:1 but the behavioral change means figuring out which of the three new rules individual config entries / inline comments map to.

...heck, now that I post this, I'm liking deletingban-types and just leaving a tombstone page. cc @typescript-eslint/triage-team - we can always add back the old deleted rule if trying out on community repos surfaces a lot of pain (#9141), right?

Makes sense to me too...
If we do that for this rule, should we just go ahead and do that for#8821, too, though?

@kirkwaiblinger we can land#8821 against main and then remove it in v8
similarly we could technically land this PR in main and then removeban-types in v8 (which is what I originally suggested#8977 (comment)).

I.e. we could backport the new rules to v7 so they're available right now, deprecateban-types, and then do the actual breaking change (removingban-types) in v8.

I like it. Once this PR goes in I can send a followup to backport the changes to v7 /main, replacing the deletion with a deprecation.

Thought: should the two new rules checkimplements andextends? You can't extendnumber or() => {} so the use ofNumber must either be intentional or refer to another type (since we still don't have scope analysis for this rule)

Someone could, in theory, be doing:

• extends:interface MyFunction extends Function { __brand: 'my-function'; }
• implements:class Weird implements Function { apply: ...; ... }.

...so for completeness, I think we need to?

Is that a bad idea? If they do it there's no reason they are doing it by accident or ignorance.

I'm not strongly opposed to removing this for simplicity. It does feel a little weird to me to leave in a known thing that nobody should really ever do - even if it's only doable with great intent.

Let's leave them in for now, but at leastextends Function feels fine to me.

For flow, you might link this and the next sentence with a conjunction such as "..., since ..." or something like that.

I like the idea but can't think of phrasing I like here to go with it. Do you have a suggestion?

@kirkwaiblinger I really want to get this in to unblock testing on community repos, so I'm merging now - but let's definitely revisit the docs before v8 goes stable!

see#9363