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

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read 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 like true and "", arrays like [], and general class instances like new Error().

Because users so often get confused by {} allowing primitives like true and "", the ban-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 the recommended* configs vs. the strict* configs.

Proposal: let's remove the restriction on {} from the default ban-types options in recommended configs, and leave them in for strict configs?

Fail

let value: Object;

Pass

let value: {};

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 and ban-types