[wontfix] fix(checker): Allow element access expressions in computed property names if argument is literal

[kairosci]

Fixes #25083.

This PR relaxes the check for computed property names in type literals (specifically in isLateBindableAST) to allow ElementAccessExpression when the argument is a static literal.

Changes

Checker (src/compiler/checker.ts)

• Updated isLateBindableAST to use a new helper isLateBindableExpression.
• isLateBindableExpression recursively checks the expression and allows:
  • String literals (e.g., Enum['key'])
  • Numeric literals
  • Signed numeric literals (e.g., Enum[-1])
  • Parenthesized expressions (e.g., Enum[('key')])

Utilities (src/compiler/utilities.ts)

• Updated isComputedNonLiteralName to also check for isSignedNumericLiteral
• Updated tryGetTextOfPropertyName to handle signed numeric literals in ComputedPropertyName, aligning with getPropertyNameForPropertyNameNode

Example

enum Type {
  '3x14' = '3x14'
}
enum Numeric {
    Negative = -1,
}

type TypeMap = {
  [Type['3x14']]: any;       // Now valid
  [Numeric['Negative']]: any; // Now valid
  [Numeric[('Negative')]]: any; // Now valid
}

Verified with new test case tests/cases/compiler/enumKeysInTypeLiteral.ts covering these scenarios.

[Copilot]

Pull request overview

This PR fixes issue #25083 by allowing element access expressions (e.g., Enum['key']) as computed property names in type literals when the argument is a literal. Previously, only dot notation (e.g., Enum.key) was accepted for enum members in computed property names.

Changes:

• Modified isLateBindableAST to use a new helper isLateBindableExpression that recursively validates element access chains with literal arguments
• Updated utility functions to handle signed numeric literals in computed property names
• Added test case covering enum keys accessed via bracket notation in type literals

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tests/cases/compiler/enumKeysInTypeLiteral.ts	New test case demonstrating enum element access with bracket notation in type literals
tests/baselines/reference/enumKeysInTypeLiteral.*	Baseline files for the new test showing expected types, symbols, and JS output
tests/baselines/reference/isolatedDeclarationLazySymbols.*	Updated baselines reflecting improved type inference for element access expressions
src/compiler/checker.ts	Added isLateBindableExpression helper and modified isLateBindableAST to handle element access chains
src/compiler/utilities.ts	Updated isComputedNonLiteralName and tryGetTextOfPropertyName to handle signed numeric literals; formatting improvements

[Copilot]

Pull request overview

Copilot reviewed 40 out of 40 changed files in this pull request and generated 2 comments.

[Copilot]

The fall-through comment indentation changes in this file appear to be unrelated to the main fix for enum keys in type literals. While the new formatting is correct, these changes should ideally be in a separate commit or PR focused on code style/formatting cleanup.

If these changes are intentional cleanup, they should be mentioned in the PR description. If they were accidental changes from an auto-formatter, consider reverting them to keep this PR focused on the bug fix.

[Copilot]

The check in the while loop is too restrictive. It should also allow EntityNameExpression (identifier or property access) as arguments, not just literals.

The current code only accepts string/numeric literals or signed numeric literals, which breaks late-bound property assignments like foo[_private] = "ok" where _private is an identifier variable.

The condition should be:

if (!isStringOrNumericLiteralLike(argument) && 
    !isSignedNumericLiteral(argument) && 
    !isEntityNameExpression(argument)) {
    return false;
}

This allows both the new use case (Enum['key'] with literal arguments) and the existing use case (foo[symbol] with identifier arguments).

[typescript-bot]

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:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate