feat(es/parser): add opt-in parser-only TSRX lowering - #12120

🦋 Changeset detected

Latest commit: c8cb07a

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

All committers have signed the CLA.

Merging this PR will regress 1 benchmark

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 198 untouched benchmarks
⏩ 61 skipped benchmarks¹

Performance Changes

_{Comparing trueadm:codex/tsrx-parser (c8cb07a) with main (3802924)²}

Review of TSRX parser/AST support

Reviewed commit 1249697fcafdc719c6978f1bd8748d9f9febfda6 against the existing SWC APIs and the canonical TSRX parser used by Ripple/Octane. The follow-up commits correctly fix ordinary-JSX shorthand: false serialization and add the required major-version Cargo changeset. The following issues remain.

1. Current plugin CI fails with an unhandled unknown AST variant

The current plugin-backend job fails with:

error[E0004]: non-exhaustive patterns:
`&mut TsrxExpr::Unknown(_, _)` not covered
--> crates/swc_ecma_ast/src/expr.rs:419:36

The nested match in Expr::set_span does not handle the generated unknown variant when plugin builds enable swc_ast_unknown and encoding-impl. Add the same conditional fallback already used by the enclosing match:

#[cfg(all(swc_ast_unknown, feature = "encoding-impl"))]
_ => swc_common::unknown!(),

2. Published JavaScript AST types and visitor do not support the returned nodes

@swc/types adds tsrx?: boolean but does not define the TSRX AST interfaces, add TSRX nodes to Expression / JSXElementChild, add JSXExpressionContainer to JSXElementName, or expose the JSXAttribute.shorthand field.

The existing @swc/core visitor is also unchanged. Executing it against nodes from the committed TSRX fixtures produces:

visitExpression(JSXCodeBlock)               -> undefined
visitJSXElementChild(JSXIfExpression)       -> undefined
visitJSXElementName(JSXExpressionContainer) -> undefined

Because visitor callers assign those results back into the AST, valid directive children and dynamic tag names are silently replaced with undefined. Please add the public node types, visitor dispatch/traversal, and JS-facing parse/visit regression tests.

3. The serialized AST is not compatible with the canonical TSRX / Octane contract

See the new AST definitions and catch-clause shape. The isAwait spelling also conflicts with SWC's existing ForOfStmt, which explicitly serializes is_await as await. If this parser is intended to feed existing TSRX/Octane tooling, align these shapes or define and test an explicit adapter.

4. JSX text containing directive-like words is incorrectly tokenized

is_tsrx_directive_start treats @if, @for, @switch, and @try followed by any nonidentifier character as directives. Valid text such as:

<div>@if</div>
<div>contact@if.com</div>
<div>@try me</div>

is therefore routed into directive parsing. The canonical TSRX parser accepts these as JSXText; it only recognizes a directive when the next non-whitespace token has the required ( or { shape.

5. Minified @else if becomes invalid @elseif

The TSRX code generator uses formatting_space! between else and a nested if. That space disappears when minifying:

@if (a) { <A /> } @else if (b) { <B /> }
// currently minifies to: @if(a){<A/>}@elseif(b){<B/>}

Use mandatory space! for this token boundary and add a minified @else if round-trip regression.

6. Template loop/switch bodies miss normal break/continue contexts

@for bodies and @switch cases are parsed without the normal IsBreakAllowed / IsContinueAllowed contexts established by ordinary SWC loop/switch parsing. Valid canonical TSRX such as:

@for (const x of xs) { if (x) continue; <A /> }
@switch (x) { @case 1: { if (x) break; <A /> } @default: { <B /> } }

therefore produces loop-control diagnostics.

7. Code-block render validation and source spans are incomplete

parse_tsrx_code_block parses an unrestricted statement block and extracts only its final JSX/directive expression. This incorrectly accepts:

function X() @{ <A />; <B /> }        // first render node silently treated as setup
function X() @{ <A />; const x = 1 } // rendered output silently disappears

The canonical parser rejects both: code blocks contain at most one rendered output, and setup cannot follow it. Explicit @{ ... } node spans also start at {, omitting the authored leading @.

8. @try / @catch grammar differs from canonical TSRX

The try parser requires parenthesized identifier-only catch parameters, so it rejects supported forms such as:

@try { <A /> } @catch { <B /> }
@try { <A /> } @catch ({ message }) { <B /> }
@try { <A /> } @catch (error: Error, reset: () => void) { <B /> }

It also incorrectly accepts @try { <A /> } without either @pending or @catch.

9. Additional validation and output regressions

• Dynamic JSX tags currently accept expressions such as <{getTag()}> and <{1}>, which the canonical TSRX parser rejects.
• @for accepts invalid await forms and duplicate or misordered index / key options.
• JSXOpeningElement emission now inserts mandatory spaces before every attribute in every mode. Existing preserved-JSX minification can emit <div a={1}b={2}/>; this change expands it to <div a={1} b={2}/>, growing ordinary JSX output even when TSRX is disabled.

Suggested coverage: plugin builds with swc_ast_unknown, JS parse/type/visitor integration, canonical TSRX AST-shape assertions, literal @if/email JSX text, minified @else if, template break/continue, invalid multiple-render blocks, catch variants, dynamic-tag validation, @for option validation, and unchanged ordinary-JSX minification.

Thank you for putting this together and for the substantial work behind it.

At this point, we don't think TSRX has the level of adoption needed for SWC to support it as a first-class syntax on the same level as JSX. Supporting new syntax at the parser and AST level carries significant long-term maintenance and ecosystem costs, so TSRX would need to become comparably well-known and widely used before we could consider this level of support.

For clarification, parser-level stripping is a special-case feature that we provide only for Flow. It should not be considered a general extension point or precedent for supporting other syntax dialects.

Given that, we're going to close this PR for now. If TSRX gains substantially broader adoption in the future, we can revisit the discussion. Thank you again for the proposal and all the effort you put into it.

At this point, we don't think TSRX has the level of adoption needed for SWC to support it as a first-class syntax on the same level as JSX. Supporting new syntax at the parser and AST level carries significant long-term maintenance and ecosystem costs, so TSRX would need to become comparably well-known and widely used before we could consider this level of support.

Thank you for reviewing this PR.

I disagree that TSRX needs the same level of adoption as JSX. That's simply not attainable, it's actually impossible. There are literally hundreds of billions of JSX/TSX modules on Github. With AI that will only continue to explode. By not helping an exciting project, just like how others helped SWC grow at the beginning by supporting SWC in their toolchain (such as rspack), you're denying us a valid route into helping TSRX become viable for large enterprise monorepos where there are likely to be thousands of TSRX modules and where build times are paramount. We offered to maintain the code and have it behind a feature flag too – but I guess there's still too much maintenance burden.

You and the team have done some fantastic work, and I remember our healthy discussions on these topics whilst we worked together at Vercel. I look forward to re-visiting this in the future if possible. You've gotta help the small-fish every once in a while, because once upon a time SWC was the small fish too.

I think TSRX has a lot of potential, and at the same time, I can understand Donny/강동윤 (@kdy1)'s concerns around long-term maintenance and binary size.

I guess a custom Rspack loader or Rsbuild plugin could be a practical alternative. It would only process .tsrx files, so the impact on overall build performance should be limited. The loader only needs to transform TSRX syntax, with the resulting code continuing through builtin:swc-loader.

As an independent compilation step, the loader could be implemented using either Oxc or SWC and evolve separately. This would give TSRX a practical integration path today while leaving the door open to native support in the future.

Reopening for personal experiments