Merging this PR will not alter performance

✅ 52 untouched benchmarks
🆕 5 new benchmarks
⏩ 14 skipped benchmarks¹

Performance Changes

_{Comparing oxc-react-compiler (cb9681f) with main (7d89909)}

Excited to see this! Happy to help test if you need

Yay!

Can't wait for this! 🚀

Binary-size root-cause analysis

Following up on the +5.14 MiB the napi addon gains (3.51 → 8.66 MiB, release/stripped) — I dug into where it comes from. (cargo bloat won't take the napi cdylib directly, so I profiled the oxc_react_compiler example, which is a bin and isolates the React Compiler's footprint cleanly. LTO-off + unstripped so symbols survive.)

cargo bloat --crates (example, .text 5.7 MiB)

Transitive deps the React Compiler drags in (confirmed RC-only via cargo tree -i)

• serde + serde_core + serde_json ≈ 757 KiB — from every forked_react_compiler* crate.
• regex engine ≈ 454 KiB — sole source is forked_react_compiler (not in the baseline transform).
• indexmap ≈ 37 KiB, sha2 ≈ 8 KiB (from reactive_scopes).
• (num_bigint is baseline oxc via oxc_ecmascript — not the React Compiler.)

Root cause

The Rust port kept the JS plugin's interface: compile_program hands its result back as a JSON-serialized Babel AST that oxc_react_compiler immediately re-parses in the same process —

let result = react_compiler::…::compile_program(file, scope_info, options); // -> JSON string (RawValue)
let value: serde_json::Value = serde_json::from_str(raw_json.get()).ok()?;   // parse JSON
serde_json::from_value(value).ok()                                          // deserialize back to File

That forces a full Serialize impl for the whole Babel AST (to emit the JSON) and a full Deserialize impl (to read it). On a type that large, that derive pair is why react_compiler_ast is 80% serde and why serde/serde_json get pulled in.

Takeaways (~half of the bloat is reducible, none of it in oxc itself)

• ~1.5 MiB is the genuine compiler-pass logic (HIR, inference, reactive scopes, validation, lowering, …) — inherent.
• ~1.2 MiB is reducible third-party transitive code, both fixable upstream in forked_react_compiler:
  • serde/JSON round-trip (~757 KiB): have compile_program return the Rust react_compiler_ast::File directly instead of a JSON string — both ends are in-process Rust, so the RawValue → Value → File round-trip is pure overhead (it's runtime cost too, not just size).
  • regex engine (~454 KiB): I couldn't find a Regex:: use in the crate's own src; worth confirming it's actually exercised, and if its usage is light, regex-lite / hand-rolled matching would reclaim most of it.

@Boshen I don't know if they would act upon it, but is it worth passing this upstream to the React team? Amazing work to you and the React team by the way, I can't wait to use this!

Bumped forked_react_compiler 0.1.0 → 0.1.1 — napi addon −0.85 MiB

Following up on the binary-size root-cause comment above: forked_react_compiler 0.1.1 lands the regex → regex-lite swap I suggested, so I bumped the dependency and re-measured.

What 0.1.1 brings

• regex → regex-lite (via a package rename in the fork's Cargo.toml). The heavy regex engine is gone from the React Compiler's dependency tree — it now only reaches the graph through env_logger/quickcheck dev-deps of oxc_allocator, which aren't linked into the release addon.
• A newer react_compiler_ast snapshot, which required adapting the AST conversion in oxc_react_compiler:
  • FunctionExpression / ObjectMethod gained a predicate field (Flow %checks) → set to None.
  • PatternLike gained a TypeCastExpression variant (a Flow node oxc never emits) → grouped with the existing TS type-wrapper arms in both conversion directions.
  • All 7 round-trip tests still pass; full-workspace cargo lint -- -D warnings is clean.

Binary size — napi transform addon (darwin-arm64, release / stripped)

Where it went — cargo bloat on the oxc_react_compiler example

The ~456 KiB regex engine — plus its std monomorphization, which is why the addon drops more than the raw ~420 KiB crate delta — is replaced by 36 KiB of regex-lite. This realizes the larger of the two reductions flagged earlier. The serde/JSON round-trip (~757 KiB) remains the next reducible chunk, and would need the upstream compile_program to return the Rust File directly instead of a JSON string.

Removing the JSON round-trip — perf

forked_react_compiler 0.1.2's compile_program returns the typed Babel File by value instead of a pre-serialized JSON string, so the transform consumes it directly. That deletes an in-process File → JSON string → serde_json::Value → File round-trip on every transformed file.

Wall-clock transformSync(…, { reactCompiler: true })

napi addon, darwin-arm64, release:

The React Compiler's added overhead on App.tsx (with-RC − without-RC) drops roughly in half (~10.8 → ~5.8 ms). The without-RC baseline jitters ~1 ms run-to-run (it never touches the compiler), so read the overhead as "≈ halved" — but the with-RC totals above are direct measurements and the −4.1 ms gap is well clear of the noise.

Why it scales with file size: the round-trip serialized the entire program's Babel AST to a JSON string, parsed it to a serde_json::Value (to de-dup duplicate "type" keys from BaseNode.node_type + #[serde(tag = "type")]), then deserialized to File — all in the same process. That work is proportional to AST size, so it pays off most on large files and is negligible on small ones. Output is byte-identical.

Binary size (same change)

With nothing left serializing/deserializing the Babel AST, fat-LTO drops the now-dead react_compiler_ast serde code:

Cumulative with the earlier regex → regex-lite swap, both reducible clusters are now gone: 8.66 MiB (0.1.0) → 7.06 MiB (0.1.2), −1.60 MiB (−18.5%) — the rest is genuine compiler logic.

AI-assisted analysis update.

I ran the React Compiler output comparison across all ecosystem CI JS/TS files under /Users/boshen/github/oxc-project/oxc-ecosystem-ci/repos after the latest fixes in 770880819d.

Summary:

• Total files compared: 209,611
• Normalized same output: 154,726
• Remaining buckets:
  • code-diff: 25,687
  • oxc-error: 34
  • babel-error: 5,815
  • both-error: 23,333
  • babel-output-parse-error: 5
  • both-output-parse-error: 7
  • empty-import: 4, but these are classifier false positives, not real import {} from regressions

High-signal OXC-only corruption buckets are now empty:

• oxc-output-parse-error: 0
• placeholder: 0
• bigint-nn: 0
• empty-class: 0
• namespace-export: 0
• lost-typeof-import: 0

The remaining code-diff bucket is mostly expected or printer-level parity noise:

• Babel strips TypeScript types while OXC preserves them.
• Numeric literal formatting differs, e.g. 1000 vs 1e3, hex vs decimal, separators.
• String escaping differs, e.g. unicode escapes vs literal unicode.
• Runtime import style differs in some script/CommonJS cases.
• Object shorthand / expanded property printing and other formatting-level differences.

One semantic-looking remaining diff needs follow-up:

• vscode/extensions/github/src/pushErrorHandler.ts
• OXC output currently emits const [octokit, x_0] = await ..., but later code still references ghRepository.
• That looks like a real rename mismatch around destructuring/renamed compiler temporaries, not a harmless formatting difference.

Local verification already run and passed:

• just fmt
• cargo test -p oxc_react_compiler
• cargo test -p oxc_codegen
• git diff --check

AI-assisted follow-up: pushed beeda5045e for the source-snippet span fix and 3d5fabd0f8 for broader regression coverage.

Root cause for vscode/extensions/github/src/pushErrorHandler.ts:

• React Compiler rename metadata only had unrelated earlier renames, e.g. x -> x_0.
• The reverse converter re-parsed source-preserved snippets with local spans starting at 0.
• The later apply_renames pass uses original source offsets, so an unrelated rename-plan offset collided with an identifier inside a source-reparsed class body.
• That produced const [octokit, x_0] = ... while later references still used ghRepository.

Fix:

• Source-reparsed statements/expressions/types now have their spans shifted back to original source offsets before apply_renames runs.

Additional tests now cover:

• the original exported-class collision shape,
• source-preserved class expressions,
• source-reparsed TypeScript type annotations.

Verification:

• just fmt
• cargo test -p oxc_react_compiler (30 passed)
• git diff --check
• PR CI is green on head 3d5fabd0f853b3dfed774a14369ca42f0d6b028f.
• Rechecked the VS Code pushErrorHandler.ts output shape: it now keeps const [octokit, ghRepository] and no longer emits const [octokit, x_0].

Suggested next step: rerun the full ecosystem comparison on current head, since the previous full compare was before the source-span fix.

Why the converter does JSON conversion for TypeScript

A heads-up for review, since it looks unusual.

The upstream Babel AST (react_compiler_ast) stores every TypeScript field as an opaque serde_json::Value, not as a typed node:

pub type_annotation: Option<Box<serde_json::Value>>,
pub type_parameters: Option<Box<serde_json::Value>>,
pub return_type:     Option<Box<serde_json::Value>>,
// TSAsExpression / TSSatisfiesExpression / TSTypeAssertion: type_annotation: Box<serde_json::Value>

The React Compiler analyzes JavaScript value/runtime semantics (memoization, reactivity) and never inspects types, so the fork keeps them as pass-through JSON instead of modeling the full TS type AST. Everything else in the Babel AST is fully typed — only the type-system fields are JSON.

Because oxc's AST is fully typed, the converter has to translate at the boundary:

• Forward (convert_ast.rs, oxc → Babel): serialize oxc's TS nodes into Babel-shaped JSON to populate those serde_json::Value fields.
• Reverse (convert_ast_reverse.rs, Babel → oxc): turn the JSON back into typed nodes — preferring to re-parse the type from the original source span (the JSON is a lossy approximation), and only falling back to reconstructing from the JSON structure.

Types have to survive this round-trip because the compiled output is handed to the downstream TypeScript transform, even though the compiler itself ignores them.

This is only the per-type-field JSON. The whole-File serialize→deserialize round-trip was already removed in the 0.1.2 bump (compile_program now returns the File by value).

Merge activity

• Jun 8, 1:31 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jun 8, 1:32 PM UTC: Boshen added this pull request to the Graphite merge queue.
• Jun 8, 1:37 PM UTC: Merged by the Graphite merge queue.