Fix #25083: Allow bracket notation for enum keys in computed properties#62978
Closed
RodrigoSanchezDev wants to merge 2 commits intomicrosoft:mainfrom
Closed
Conversation
… properties This commit fixes an issue where using bracket notation to access enum members (e.g., Type['key']) was not accepted in computed property names of type literals, even though dot notation (e.g., Type.key) worked fine. The problem was in the isLateBindableAST function in checker.ts, which only accepted EntityNameExpression. Element access expressions like Type['key'] were rejected even though they resolve to the same literal type as their dot notation equivalents. Changes: - Modified isLateBindableAST to accept ElementAccessExpression when the base object is an EntityNameExpression - This enables bracket notation for accessing enum members with non-identifier names (e.g., '3x14' or names starting with digits) - Added comprehensive test case covering various scenarios including identifier and non-identifier enum keys with bracket notation Fixes microsoft#25083 Signed-off-by: Rodrigo Sanchez <Rodrigo@sanchezdev.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes issue #25083 by enabling bracket notation (Type['key']) for enum members in computed property names within type literals, making it consistent with the existing dot notation (Type.key).
Changes:
- Modified
isLateBindableASTto acceptElementAccessExpressionwhen the base is anEntityNameExpression - Added comprehensive test coverage for both identifier and non-identifier enum keys using bracket notation
Update reference baselines for the new test case that demonstrates bracket notation working correctly with enum keys in computed properties. Signed-off-by: Rodrigo Sanchez <Rodrigo@sanchezdev.com>
Collaborator
|
With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies). Next steps for PRs:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #25083
This PR enables bracket notation (e.g., Type['key']) to work alongside dot notation (Type.key) when using enum members as computed property names in type literals.
Problem: Bracket notation was rejected even though it resolves to the same literal type.
Solution: Modified isLateBindableAST to accept ElementAccessExpression when the base is an EntityNameExpression.
Testing: Added comprehensive test case covering identifier and non-identifier enum keys.
This makes TypeScript more consistent by treating Type.Foo and Type['Foo'] equivalently in computed property contexts.