Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/typescript-eslint/typescript-eslint/issues/8700 below:

[ban-types] Split the {} ban into a separate, better-phrased rule · Issue #8700 · typescript-eslint/typescript-eslint · GitHub

• 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.

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

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

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.

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

• This one: holistically rethinking ban-types, which might take some time
• Enhancement: [ban-types] Allow {} in the recommended config #8697: spot improving the recommended experience, which can land first

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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4