Before You File a Proposal Please Confirm You Have Done The Following...

• I havesearched for related issues and found none that match my proposal.
• I have searched thecurrent rule list and found no rules that match my proposal.
• I haveread the FAQ and my problem is not listed.

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/ban-types

Description

The{} has long been a source of confusion in TypeScript. It means"any non-nullish value, but with no known fields". That includes objects like{} and{ value: 1 }, primitives liketrue and"", arrays like[], and general class instances likenew Error().

Because users so often get confused by{} allowing primitives liketrue and"", theban-types rule suggests users use something more restrictive. Specifically its default options include:

`{}` actually means "any non-nullish value".',- If you want a type meaning "any object", you probably want `object` instead.',- If you want a type meaning "any value", you probably want `unknown` instead.',- If you want a type meaning "empty object", you probably want `Record<string, never>` instead.',- If you really want a type meaning "any non-nullish value", you probably want `NonNullable<unknown>` instead.',

That's pretty strict... at the cost of user convenience.

Now that#8364 is in, we have the ability to provide more lenient default options for therecommended* configs vs. thestrict* configs.

Proposal: let's remove the restriction on{} from the defaultban-types options inrecommended configs, and leave them in forstrict configs?

Fail

letvalue:Object;

Pass

letvalue:{};

Additional Info

@RyanCavanaugh, the dev lead for TypeScript, is not a fan of the way it is now 😄:https://bsky.app/profile/searyanc.dev/post/3knqtqcjhpn2d

See also#5947 for past discussion around objects andban-types