-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat(eslint-plugin): [no-unsafe-enum-comparison] add switch suggestion #7691
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): [no-unsafe-enum-comparison] add switch suggestion #7691
Conversation
Thanks for the PR, @StyleShit! 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. |
8725058
to
0471e12
Compare
OK, should be better now, but I still can't figure out the types there 😓 |
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.
Really good start so far! The code looks clean and I like the general direction. 😄
Left a few comments and suggestions for how to overcome the // @ts-expect-error
s. I suspect they'll end up showing you a bunch more test cases to add. Have fun!
packages/eslint-plugin/tests/rules/no-unsafe-enum-comparison.test.ts
Outdated
Show resolved
Hide resolved
packages/eslint-plugin/tests/rules/no-unsafe-enum-comparison.test.ts
Outdated
Show resolved
Hide resolved
…suggestion' into tweak/no-unsafe-enum-comparison-suggestion
…nsafe-enum-comparison-suggestion
* - Fruit.Apple | Vegetable.Lettuce --> [Fruit.Apple, Vegetable.Lettuce] | ||
* - Fruit.Apple | Vegetable.Lettuce | 123 --> [Fruit.Apple, Vegetable.Lettuce] | ||
* - T extends Fruit --> [Fruit] | ||
*/ |
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.
[Praise] Great comments, thanks for continuing the existing standard 🙂
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.
'a' = 1, | ||
} | ||
declare const stringKey: StringKey; | ||
stringKey === StringKey['a']; |
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.
StringKey['a'];
Just confirming explicitly in case someone looks at this in the future: I think it's fine to have it look like StringKey['a']
instead of StringKey.a
. They're functionally the same, and there are other rules around stylistic concerns.
…nsafe-enum-comparison-suggestion
return `${enumName}['${memberNameIdentifier.text}']`; | ||
|
||
case ts.SyntaxKind.ComputedPropertyName: | ||
return `${enumName}[${memberNameIdentifier.expression.getText()}]`; |
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.
had to use .getText()
here, there is no .text
for some reason
seems like it's fine? See the tests for that as a reference
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 type of memberNameIdentifier.expression
is ts.Expression
, which is a pretty wide type. You could as
assert it to the union of types that are actually allowed as enum member names... or just go with .getText()
. If the unit tests aren't showing any bad behavior, it's probably fine. 😎
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 probably keep it like this, seems fine in the tests (unless I'm missing some cases?)
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 existing bugs in #7768 make me not too motivated to get every single possible edge case in this PR. The tests you've added are pretty great. Thanks!
…nsafe-enum-comparison-suggestion
enum ComputedKey { | ||
[\`test- | ||
key\` /* with comment */] = 1, | ||
} |
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.
(Why is this even legal?!)
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.
to make our lives harder 🫠
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.
It's hard enough without it! 😭
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.
Nice! Great investigation resulting in a nice set of test coverage & fixing. Thanks for working with me on this on @StyleShit!
We can always tackle more edge cases in the followup #7768.
Closes #7643