Enhancement: [ban-types] Allow {} in the recommended config

[JoshuaKGoldberg]

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

[JoshuaKGoldberg]

Just read microsoft/TypeScript#57735 and filed #8700 as a result. For clarity, the intent of the two issues I'm filing are:

• Enhancement: [ban-types] Split the {} ban into a separate, better-phrased rule #8700: holistically rethinking ban-types, which might take some time
• This one: spot improving the recommended experience, which can land first

If #8700 is resolved before this one, that's great too.

[bradzacher]

Strong 👎
See #8700 (comment)

(this issue and #8700 also seem like duplicates?)

[Josh-Cena]

From what I understand: this is about removing the ban in recommended, while #8700 is about removing the ban everywhere...

[bradzacher]

They're one and the same though. The rule supports banning {} but it only flags it because it's in the default config. If you remove it from the default config then it's removed from everywhere.

[JoshuaKGoldberg]

As of #8364 we can have different default options for recommended and strict. That's what I meant for this issue.

But yeah, I wasn't sure whether to file this and/or #8700 as a single issue, or discussion, or etc.. Marking this one as blocked on resolving discussion there in the interim.

[JoshuaKGoldberg]

Closing per #8700 (comment). We can always revisit this if v9 shows that many users are still confused by the {} ban with the new, better-phrased rule.