Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Changes from 5 commits
bcfbb03
173251c
b83cb50
39870f1
f90ab3f
0a5c2bd
c01f10e
f021d26
ca7fb0f
fad7a5e
e8a2d7f
3971d71
d33a246
28ed70d
9b6dd1a
e0bbd1d
b7a70b8
713404a
218d8e5
9987c2b
bd764ef
7dc88d7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 feel like these two rules are really one, maybe as an option
allowInterface
for declaration mergingThere 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.
Hmm, I see them as separate rules. They're definitely related but I think the justifications for disabling either are very different.
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.
interface T {}
is not any different fromtype T = {}
by itself, though. The motivation says:That is exactly applicable to empty object types. There is only slightly more reason to disable
no-empty-interface
because it allows declaration merging.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.
Interesting. I'll need to think on that a bit... Just confirming, you're suggesting we should merge
no-empty-interface
into this rule for v8, too?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.
Yes, exactly.
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.
the difference between the two is that
no-empty-interface
allows you to baninterface Foo extends Bar {}
in favour oftype Foo = Bar
.However a similar rule doesn't make sense for type aliases.
But there's no reason we couldn't merge them and keep the
allowSingleExtends
option just for interfaces.but you're JoshG isn't wrong - the scope is different because the current form bans
{}
anywhere - not just intype
aliases.I personally can't think of a reason you'd ever want to have one banned, but not the other.
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.
Heh, I don't have a strong preference either way, and it sounds like the current consensus is leaning towards unification? Unless @kirkwaiblinger has strong input I'm up for unifying.
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.
no strong opinions on this!
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 will say, though, it does feel like yet another breaking change for users just to preserve the existing behavior. So, I guess "no strong opinion" defaults to not merging in this case 🤷
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 would have said the opposite - it's a breaking change TO merge.
Cos if you don't merge - people are just switching from
ban-types
to this new rule.But if you merge they ALSO need to switch from
no-empty-interface
to this new rule.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 confuseObject
for{}
.Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.