New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(eslint-plugin): split no-empty-object-type out from ban-types and no-empty-interfaces #8977
feat(eslint-plugin): split no-empty-object-type out from ban-types and no-empty-interfaces #8977
Conversation
Thanks for the PR, @JoshuaKGoldberg! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
@@ -82,32 +85,6 @@ const defaultTypes: Types = { | |||
'If you are expecting the function to accept certain arguments, you should explicitly define the function shape.', | |||
].join('\n'), | |||
}, | |||
|
|||
// object typing | |||
Object: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We didn't explicitly discuss Object
, but I think it makes sense in the spirit of this change to switch it to being treated as another banned uppercase alias. I've never seen people confuse Object
for {}
.
Co-authored-by: Kirk Waiblinger <53019676+kirkwaiblinger@users.noreply.github.com>
Co-authored-by: Kirk Waiblinger <53019676+kirkwaiblinger@users.noreply.github.com>
Mildly tangential - but I can envision the following options:
|
This comment was marked as resolved.
This comment was marked as resolved.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## v8 #8977 +/- ##
==========================================
- Coverage 87.43% 87.34% -0.09%
==========================================
Files 386 387 +1
Lines 13069 13025 -44
Branches 3776 3769 -7
==========================================
- Hits 11427 11377 -50
- Misses 1353 1356 +3
- Partials 289 292 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Also worth noting that we could land this as a standalone rule for v7 and then in v8 we change the defaults and make this new rule recommended. That would allow us to do a deprecation of |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
general logic LGTM
|
||
### `allowObjectTypes` | ||
|
||
Whether to allow empty object type literals, as one of: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this list is stale now, due to the new option being added, right? Or, I guess, the way it's written, it doesn't seem to me like allowWithName
is part of the list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having a hard time thinking of phrasing for this 🤔 do you have any suggestions @kirkwaiblinger?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merged so that I can get other PRa going, but happy to take a followup issue or PR!
Co-authored-by: Kirk Waiblinger <kirk.waiblinger@gmail.com>
BREAKING CHANGE:
Changes the default options of a lint rule
PR Checklist
Overview
Per #8700 (comment), splits out the banning of
{}
from theban-types
rule into a newno-empty-object-type
rule.