Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
feat(typescript-estree): computed members discriminated unions#1349
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Thanks for the PR,@bradzacher! 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 onhttps://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitorsper day. |
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
f8cc808
to811ad0a
CompareUh oh!
There was an error while loading.Please reload this page.
packages/typescript-estree/tests/ast-alignment/fixtures-to-test.ts OutdatedShow resolvedHide resolved
Uh oh!
There was an error while loading.Please reload this page.
property names are either `computed: false` with `key: Identifier | StringLiteral | NumberLiteral`, or they are `computed: true` with `key: Expression`.the previous typings took the simple approach of just having a single type, but it made things a bit more cumbersome.This change creates two types for each, using the `computed` value as the key for a discriminated union.This means that if you check `node.computed === true`, then TS will narrow the `key` type appropriately.I also noticed a minor bug in the `TSEnumMember` handling, as the types didn't previously support the fact that it's syntactically valid to use an expression (note it's semantically invalid - TS error 1164).It's also semantically and syntactically valid to do something like `enum Foo { ['key'] }`, which really should be handled differently to `enum Foo { key }`, even if they mean the same thing.So I also added a `computed` prop to `TSEnumMember`, and gave it the same discriminated union treatment.
b026aad
toe91a7fe
Comparecodecovbot commentedDec 19, 2019 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Codecov Report
@@ Coverage Diff @@## master #1349 +/- ##=========================================- Coverage 94.01% 94% -0.02%========================================= Files 131 131 Lines 5867 5867 Branches 1662 1663 +1 =========================================- Hits 5516 5515 -1 Misses 186 186- Partials 165 166 +1
|
armano2 left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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.
besides this 2 missing test cases
LGTM 👍
Uh oh!
There was an error while loading.Please reload this page.
Fixes#1345
Property names are either
computed: false
withkey: Identifier | StringLiteral | NumberLiteral
, or they arecomputed: true
withkey: Expression
.the previous typings took the simple approach of just having a single type, but it made things a bit cumbersome to use.
This change creates two types for each, using the
computed
value as the key for a discriminated union.This means that if you check
node.computed === true
, then TS will narrow thekey
type appropriately.I also noticed a minor bug in the
TSEnumMember
handling, as the types didn't previously support the fact that it's syntactically valid to use an expression (note it's semantically invalid - TS error 1164).It's also semantically and syntactically valid to do something like
enum Foo { ['key'] }
, which really should be handled differently toenum Foo { key }
, even if they mean the same thing.So I also added a
computed
prop toTSEnumMember
, and gave it the same discriminated union treatment.