`experimental.reactCompiler: true` is silently dropped (no warning, no transform)

[hyf0]

Problem

experimental.reactCompiler: true is silently dropped — no warning, and React Compiler is not applied to app code.

react.dev sets experimental: { reactCompiler: true } and ships babel-plugin-react-compiler. Under vinext the app is served with no compiler auto-memoization.

Repro

grep -rhoE 'react\.memo_cache_sentinel|useMemoCache|react/compiler-runtime|_c\([0-9]+\)' \
  dist/client/_next/static/chunks/*.js | sort | uniq -c
# only matches in framework-*.js (React itself); ZERO _c(N)/compiler-runtime in any app chunk

vinext's config parser has no handling for experimental.reactCompiler and drops it without a warning; vinext drives the app transform via oxc (not Babel), and the compiler is Babel-only in 1.0.

Impact

Parity/perf regression only — components are functionally correct but re-render without auto-memoization (production react.dev runs with the compiler).

Suggested fix

Run babel-plugin-react-compiler (target '19') over app modules when experimental.reactCompiler is set — or, at minimum, emit an "ignored" warning (like the existing experimental.swcEnvOptions one) so it isn't a silent parity gap.

[hyf0]

🔎 Triage — Next.js behavior vs vinext behavior

Method: grounded in the installed Next.js 15.1.12 source (node_modules/next/dist) and the exact vinext 0.1.8 dist (node_modules/vinext/dist) this issue was filed against; each conclusion independently re-checked by an adversarial second pass. vinext targets the Next.js 16 API surface, so a possible version difference was tested explicitly.

Verdict: 🐞 vinext bug (parity gap — fix needed) + by-design limitation · should vinext fix: partial · scope: runtime-parity · confidence: high

Next.js behavior

Next.js recognizes the React Compiler flag and runs babel-plugin-react-compiler over client app code. In 15.1.12 the key is experimental.reactCompiler (config-schema accepts boolean | {compilationMode, panicThreshold}). When set, Next resolves babel-plugin-react-compiler and injects it as a Babel pass (getReactCompilerPlugins/getReactCompilerLoader), guarded so it only runs for client (non-server) modules, producing _c(N)/react-compiler-runtime auto-memoization output. Even on the SWC/Turbopack path Next wires a dedicated react-compiler Babel loader. In Next 16 the option was promoted from experimental to a top-level reactCompiler key, but the mechanism is unchanged: still a Babel plugin (babel-plugin-react-compiler), with an SWC pre-analysis that limits which files the Babel pass touches.

_{Evidence: node_modules/next/dist/server/config-schema.js:378 · node_modules/next/dist/server/config-shared.js:201 · node_modules/next/dist/build/get-babel-loader-config.js:29-100 · node_modules/next/dist/build/swc/index.js:651-681 · https://nextjs.org/docs/app/api-reference/config/next-config-js/reactCompiler · https://nextjs.org/blog/next-16}

vinext behavior

vinext 0.1.8 has zero handling for the React Compiler: a grep across the entire dist for reactCompiler/react-compiler/compiler-runtime/babel-plugin-react returns nothing — neither the Next-15 experimental.reactCompiler key nor the Next-16 top-level reactCompiler key is read. The flag is dropped silently with no warning, and no compiler/auto-memoization transform is applied to app code. This silence is notable because vinext's config parser DOES emit ignored/unsupported warnings for analogous flags: experimental.swcEnvOptions (next-config.js:671), webpack (:681-682), experimental.lightningCssFeatures (:679), unknown lightningcss features (:487), experimental.appShells co-flags (:665). vinext's React transform runs through @vitejs/plugin-react ^6.0.1 (package.json:102); the installed v6.0.3 supports React Compiler via its reactCompilerPreset helper (@rolldown/plugin-babel + @babel/core + babel-plugin-react-compiler), so wiring it from the config flag is feasible — vinext simply never does.

_{Evidence: node_modules/vinext/dist/config/next-config.js:671 · node_modules/vinext/dist/config/next-config.js:679 · node_modules/vinext/dist/config/next-config.js:681-682 · node_modules/vinext/package.json:102 · node_modules/@vitejs/plugin-react/README.md:82}

Is it a version difference (vinext → Next 16 vs react.dev → Next 15)?

No. The config-KEY location moved between versions — experimental.reactCompiler in Next 15.1.12 (config-schema.js:378, config-shared.js:201) was promoted to a top-level reactCompiler key in Next 16 (nextjs.org/blog/next-16) — but the underlying BEHAVIOR is stable: both versions run babel-plugin-react-compiler over client app code (get-babel-loader-config.js:29-100; the Next-16 docs explicitly state it still runs through a Babel plugin). vinext supports NEITHER key — grep for reactCompiler across the whole dist is empty — so the parity gap is not explained by 15-vs-16 targeting; even a correct Next-16 top-level reactCompiler:true would be dropped identically. This is an unimplemented feature, not a genuine version-divergence.

Fix

dist/config/next-config.js — at minimum add an "ignored" console.warn alongside the existing swcEnvOptions warning (~line 671), covering both reactCompiler (Next 16 top-level) and experimental.reactCompiler (Next 15). Full fix: read the flag and wire babel-plugin-react-compiler through @vitejs/plugin-react's reactCompilerPreset (target '19') for client modules.

---

_{🤖 Triaged with Claude Code (Opus 4.8) — read-only analysis against installed Next 15.1.12 + vinext 0.1.8 sources, adversarially verified.}