Skip to content

Enhancement: [ban-types] Split the {} ban into a separate, better-phrased rule #8700

Closed
@JoshuaKGoldberg

Description

@JoshuaKGoldberg

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

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

Filing this issue as a followup/superset of the more targeted #8697. As of microsoft/TypeScript#49119, TypeScript has much better handling of {} semantics than it did when the ban-types default options were written. @RyanCavanaugh -the dev lead for TypeScript- called out in microsoft/TypeScript#57735 (comment) that as it stands today, { } is a valid type with a valid meaning in TypeScript.

Proposal: let's re-think the default options in ban-types to agree with the way TypeScript now works?

My first proposal would be, roughly...

  • Remove any bans of {} altogether, including in recommended and strict
  • Add a ban on NonNullable<unknown> that suggests switching to {}

...but I'd want to hear from @bradzacher and @RyanCavanaugh on whether that satisfies the intents of both TypeScript and ban-types.

Fail

let nonNullish: Object;

Pass

let nonNullish: {};

Additional Info

For clarity, the intent of the two issues I'm filing are:

If this issue is resolved before #8697, that's great too.

Metadata

Metadata

Labels

accepting prsGo ahead, send a pull request that resolves this issueenhancement: plugin rule optionNew rule option for an existing eslint-plugin rulelocked due to agePlease open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing.package: eslint-pluginIssues related to @typescript-eslint/eslint-plugin

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions