Open
Description
Before You File a Documentation Request Please Confirm You Have Done The Following...
- I have looked for existing open or closed documentation requests that match my proposal.
- I have read the FAQ and my problem is not listed.
Suggested Changes
One of the particularly exciting changes in our upcoming v8
version is us finally fixing up messaging around the {}
(empty object type). It's long been a contentious part of the ban-types
rule:
- On the one hand,
{}
is a confusing type that a lot of TS devs get tripped up over - On the other hand, there are legitimate use cases for it, and banning it outright is too string
We think we've reached a good compromise for v8 with the combination of:
- For
{}
, splitting out a dedicatedno-empty-object-type
rule: Enhancement: [ban-types] Split the {} ban into a separate, better-phrased rule #8700 -> feat(eslint-plugin): split no-empty-object-type out from ban-types and no-empty-interfaces #8977 - For the remaining uses of (a) configurable types and (b) uppercase aliases like
Number
, splitting out a couple of rules: Enhancement: [ban-types] Split into default-less no-restricted-types and more targeted type ban rule(s) #8978 -> feat(eslint-plugin): replace ban-types with no-restricted-types, no-unsafe-function-type, no-wrapper-object-types #9102
This has been a long journey with lots of discussion (#8700 is just one of many!). It seems ripe for a blog post to me!
💖
Affected URL(s)
https://typescript-eslint.io/blog/*
Note that if this is accepted, I think a member of our team should write the post. It's not something an external contributor could easily do. Blog posts are tricky.
Metadata
Metadata
Assignees
Labels
Documentation ("docs") that needs adding/updatingDocumentation ("docs") that needs adding/updatingA member of the typescript-eslint team should work on this.A member of the typescript-eslint team should work on this.