You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Erasing as or satisfies can expose an invalid left operand of **Β #65170
Both functions compile without diagnostics, including with --erasableSyntaxOnly. The native builds emit (-x) ** 2 and (await x) ** 2. Replacing the type syntax with spaces leaves -x ** 2 and await x ** 2, both of which Node.js rejects with a SyntaxError.
Replacing as number with satisfies number or using chained assertions reproduces the issue. Erasure also produces invalid JavaScript when it exposes an unparenthesized +, ~, !, typeof, void, or delete expression to the left of **.
π Expected behavior
The parser already rejects related cases where erasing as or satisfies changes the grouping of a binary expression (#63527 and #63661). Reporting a parser diagnostic here would be consistent with those fixes. In these examples, erasure leaves an invalid left operand for **.
Even if these forms remain accepted by default, a diagnostic under --erasableSyntaxOnly would still catch the unsafe erasure.
Explicitly parenthesized forms such as (-x) as number ** 2 and (await x) as number ** 2 should still compile.
Additional information about the issue
The original parser fix handles as and satisfies when erasure changes how surrounding binary operators bind. microsoft/TypeScript#63527
The follow-up parser fix covers the right associativity of **, where erasure can change grouping even at equal precedence. microsoft/TypeScript#63661
Ryan explained why ordinary parsing accepts await a as any ** 1 and confirmed that current emit preserves its grouping by adding parentheses. Ryanβs reply on microsoft/TypeScript#41755
What is the intended direction for fixing this? Should these expressions be rejected only with erasableSyntaxOnly, or should they be rejected in all configurations?
Activity
magic-akari commentedon Nov 4, 2026
What is the intended direction for fixing this? Should these expressions be rejected only with erasableSyntaxOnly, or should they be rejected in all configurations?
RyanCavanaugh commentedon Nov 4, 2026
The best precedent here is #63533, where the treatment of
1 + 2 as any / 3was discussed. So I think this is an error regardless of ESO.