Skip to content
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

Merged

Conversation

JoshuaKGoldberg
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg commented Apr 23, 2024

BREAKING CHANGE:
Changes the default options of a lint rule

PR Checklist

Overview

Per #8700 (comment), splits out the banning of {} from the ban-types rule into a new no-empty-object-type rule.

Screenshot of the rule's new report message on a {} type in a VS Code hover card. Quick fixes are available.

@JoshuaKGoldberg JoshuaKGoldberg added this to the 8.0.0 milestone Apr 23, 2024
@typescript-eslint
Copy link
Contributor

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.

@JoshuaKGoldberg JoshuaKGoldberg marked this pull request as ready for review April 23, 2024 19:37
@@ -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: {
Copy link
Member Author

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>
@bradzacher
Copy link
Member

Mildly tangential - but I can envision the following options:

  • allowInTypeAliasWithName - for react codebases to allow type MyProps = {}
  • allowInIntersection - to allow type T = A & {} - wherein the {} falls away.
    • does this even need an option...? Probably should be the default?

@kirkwaiblinger

This comment was marked as resolved.

Copy link

codecov bot commented Apr 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.34%. Comparing base (04f1938) to head (39870f1).

❗ Current head 39870f1 differs from pull request most recent head 7dc88d7. Consider uploading reports for the commit 7dc88d7 to get more accurate results

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     
Flag Coverage Δ
unittest 87.34% <100.00%> (-0.09%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
packages/eslint-plugin/src/rules/ban-types.ts 95.83% <ø> (-4.17%) ⬇️
...es/eslint-plugin/src/rules/no-empty-object-type.ts 100.00% <100.00%> (ø)

... and 33 files with indirect coverage changes

@bradzacher
Copy link
Member

bradzacher commented Apr 26, 2024

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 no-empty-interface this version and remove it in v8 - if we wanted to go that route.

@JoshuaKGoldberg
Copy link
Member Author

JoshuaKGoldberg commented Apr 26, 2024

standalone rule for v7

I like that a lot! Regardless of what we choose for no-empty-interface, this lets us get it released faster. Excellent. I'll get that PR up now. Edit: actually, no, I'll wait a bit - maybe it wouldn't make sense.

@JoshuaKGoldberg JoshuaKGoldberg marked this pull request as draft April 26, 2024 13:42
Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

general logic LGTM

@JoshuaKGoldberg JoshuaKGoldberg marked this pull request as ready for review May 8, 2024 15:36

### `allowObjectTypes`

Whether to allow empty object type literals, as one of:
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member Author

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!

packages/eslint-plugin/docs/rules/no-empty-object-type.mdx Outdated Show resolved Hide resolved
packages/eslint-plugin/docs/rules/no-empty-object-type.mdx Outdated Show resolved Hide resolved
packages/eslint-plugin/docs/rules/no-empty-object-type.mdx Outdated Show resolved Hide resolved
@JoshuaKGoldberg JoshuaKGoldberg changed the title feat(eslint-plugin): split no-empty-object-type rule out from ban-types rule feat(eslint-plugin): split no-empty-object-type out from ban-types and no-empty-interfaces May 12, 2024
@JoshuaKGoldberg JoshuaKGoldberg merged commit fd097ef into typescript-eslint:v8 May 12, 2024
58 checks passed
@JoshuaKGoldberg JoshuaKGoldberg deleted the no-empty-object-type branch May 12, 2024 05:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants