feat(eslint-plugin): [no-unsafe-enum-comparison] handles switch cases #7541
Conversation
|
Thanks for the PR, @Zamiell! 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. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Oh, interestingly enough, the new version of the rule found a bug at packages/eslint-plugin/src/rules/no-unnecessary-type-constraint.ts. (Well, CI passes except for |
Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
|
theres some bogus stuff going on in CI, i think a maintainer needs to look at this, as it looks unrelated to my PR. |
There was a problem hiding this comment.
Oop, I'd meant to merge changes from main after merging #7691 but I don't think I have permissions to push to your branch @Zamiell. Pushed to here instead: https://github.com/JoshuaKGoldberg/typescript-eslint/tree/enum-comparison-switch-merge
I think the lint failure in ErrorsViewer.tsx on the switch (severity) is an existing bug in the rule that just so happens to be exposed by this PR. Something imported with import type might not be a value that can actually be runtime-imported. If this is an existing bug, I think it'd be reasonable to eslint-disable it in this PR and file a followup issue. WDYT?
Otherwise 👍 LGTM for merging! We'd want to file a followup issue to get #7691's suggest: ... in switch statements too.
|
how do i give you permission? otherwise, just merge whatever changes from your own branch, as it doesn't matter to me |
|
It's on the bottom-right of the page, at the bottom of the right sidebar:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork is the closest docs page I could find on docs.github.com. I would prefer to get the changes in this PR so that it's easier to find from the Git history. And you deserve direct/primary author attribution as you've put a lot of great work into this PR! 😄 |
|
@JoshuaKGoldberg That button doesn't show up for me. Can you just use the changes from your own branch instead? |
|
Sure, no worries: #7898. I'm guessing you're not seeing the permissions because this PR was sent from an organization ( |
|
ok, should i close this PR now? |
PR Checklist
switchstatements #7509Overview
Hello, co-author of the
no-unsafe-enum-comparisonrule here.Currently, he
no-unsafe-enum-comparisonrule handles comparisons (e.g.BinaryExpression) but it does not handle switch statements. My PR makes the rule handle both.This was an oversight in my original design of this rule, and I consider this to be a bug. However, I have marked the PR as
featinstead offixto be more conservative; feel free to change it if you wish.Code Change Summary
I refactored the logic in the
BinaryExpressionselector and put it inside of a function calledisMismatchedComparison.Then, I can call that function from multiple selectors. The changes should be pretty straightforward to understand.
Other Notes
I have reworked the documentation for this rule a bit, as the original text is now no longer accurate, because TypeScript has made number enums more safe in version 5.0. Thus, I rewrote the document to focus on the string case, adding a line to emphasize that the rule is still useful if you choose to use string enums over number enums.