The Starling JS parser rejects a comma (sequence) expression inside a template-literal substitution with expected '}' to close template substitution, got Comma. The grammar allows it: a substitution holds a full Expression, so `x${1,2}` is legal and node accepts it. One parse error kills the whole script — x.com's shared~bundle.AccountAnalytics~ondemand.BusinessInsights.b1b0930a.js chunk dies on this.
What happens
ParseTemplateLiteral parses each substitution with expressions.Add(ParseAssignment()) (src/Starling.Js/Parse/JsParser.cs:1363) and then requires the next token to be } (throw at JsParser.cs:1367-1369). ParseAssignment stops at the first comma, so `x${1,2}` leaves a Comma token in the stream and the parser throws.
The grammar (ECMAScript "Template Literal Lexical Components" plus TemplateMiddleList) places Expression[+In] inside ${ } — the sequence operator is allowed.
Repro
`x${1,2}` // node: "x2". Starling JS parser: expected '}' to close template substitution, got Comma
`x${(1,2)}` // parenthesized form parses fine on both (the LParen arm already handles sequences)The chunk-level failure was verified on 2026-06-10 against the real x.com chunk with the exact message above. The minimal forms follow directly from the cited parse path.
Fix
Real fix: parse a full Expression inside template substitutions — after ParseAssignment(), loop on Comma building a SequenceExpression, exactly as the parenthesized-expression arm already does (JsParser.cs:1281-1292). No band-aid applies.
Context
Found during the x.com/nasa boot investigation on 2026-06-10 (branch feat/js-stack-trampoline). Same blast-radius pattern as the sibling parser issues (regex Unicode property escapes, parenthesized in): one parse error kills every webpack module in the chunk, and the half-evaluated modules cached by webpack surface later as misleading errors.
The Starling JS parser rejects a comma (sequence) expression inside a template-literal substitution with
expected '}' to close template substitution, got Comma. The grammar allows it: a substitution holds a fullExpression, so`x${1,2}`is legal and node accepts it. One parse error kills the whole script — x.com'sshared~bundle.AccountAnalytics~ondemand.BusinessInsights.b1b0930a.jschunk dies on this.What happens
ParseTemplateLiteralparses each substitution withexpressions.Add(ParseAssignment())(src/Starling.Js/Parse/JsParser.cs:1363) and then requires the next token to be}(throw atJsParser.cs:1367-1369).ParseAssignmentstops at the first comma, so`x${1,2}`leaves aCommatoken in the stream and the parser throws.The grammar (ECMAScript "Template Literal Lexical Components" plus
TemplateMiddleList) placesExpression[+In]inside${ }— the sequence operator is allowed.Repro
The chunk-level failure was verified on 2026-06-10 against the real x.com chunk with the exact message above. The minimal forms follow directly from the cited parse path.
Fix
Real fix: parse a full
Expressioninside template substitutions — afterParseAssignment(), loop onCommabuilding aSequenceExpression, exactly as the parenthesized-expression arm already does (JsParser.cs:1281-1292). No band-aid applies.Context
Found during the x.com/nasa boot investigation on 2026-06-10 (branch
feat/js-stack-trampoline). Same blast-radius pattern as the sibling parser issues (regex Unicode property escapes, parenthesizedin): one parse error kills every webpack module in the chunk, and the half-evaluated modules cached by webpack surface later as misleading errors.