React Compiler

React Compiler is a build-time optimization for React itself. Apps created with knext create have it on by default, on every build target. This page covers what that scaffold writes, how to turn it off, how to add it to an app you created another way, and what it does and does not affect.

New apps: on by default

knext create turns React Compiler on unless you say otherwise. On a terminal it asks "Enable React Compiler?", and Enter means yes. With --yes, in CI, or without a terminal, it is on.

To create an app without it:

knext create my-app --no-react-compiler

To turn it off in an app you already created, undo the two changes the scaffold made. The sections below list them for each target: delete the config line and uninstall the packages.

What it does, and does not, affect

React Compiler automatically memoizes components and values during the build, so your app does less unnecessary re-rendering in the browser. It is a client-rendering optimization.

It does not change:

• server response time — nothing it does runs on the server;
• cold start — knext's cold start is dominated by pod scheduling and process boot, neither of which this touches (see Scale to zero);
• knext's build pipeline, runtime image, or deploy. It is entirely a setting inside your app's own next.config.ts (or vite.config.ts on the vinext target). knext create writes that setting for you, but the build, the runtime and the CRD do not depend on it either way.

Verified working on every knext build target: the official adapter (build: 'turbopack' or 'webpack', either runtime) and the vinext target (either runtime) — six cells, each confirmed by inspecting the actual compiled output for the compiler's own memoization markers, not just a successful build.

Official adapter target (build: 'turbopack' or 'webpack')

A new app already has both of these. For an app you created another way, add reactCompiler: true to next.config.ts, and install the optional Babel plugin that performs the transform:

const nextConfig: NextConfig = {
  // ...your existing config
  reactCompiler: true,
};

npm install -D babel-plugin-react-compiler

This works identically on both bundlers (build: 'turbopack' and build: 'webpack') and both runtimes (runtime: 'bun' and runtime: 'node'). Nothing else in your knext.config.ts changes.

Eligibility matters. Next only applies the compiler to files it judges "relevant" — in practice, Client Components with real work to memoize (props, state, derived values). A trivial component with no props and nothing to recompute can be skipped even with the config on; this is Next's own documented behavior, not a knext limitation, and not something to work around.

vinext target (build: 'vinext', Beta)

A new vinext app already has the option and all four packages below. On the vinext build target, React Compiler is not a next.config.ts key — vinext does not read reactCompiler from there. It is an option on vinext's own Vite plugin, in vite.config.ts:

import vinext from 'vinext';

export default defineConfig({
  plugins: [
    vinext({
      react: { compiler: true },
      // ...your existing vinext options
    }),
    // ...
  ],
});

This needs four packages, not one — vinext resolves @vitejs/plugin-react itself but only registers the compiler when that package is 6.1 or newer; the transform itself needs the Babel plugin, a Rolldown-compatible Babel bridge (vinext's Vite dependency is Vite 8, which bundles with Rolldown), and @vitejs/plugin-react 6.1's own required peer for the non-compiler JSX transform path it also uses:

npm install -D @vitejs/plugin-react@6.1.2 babel-plugin-react-compiler @rolldown/plugin-babel oxc-transform-react@^0.152.0

Keep @vitejs/plugin-react and oxc-transform-react in step. The plugin requires one specific 0.x minor of oxc-transform-react and has changed which one in patch releases, so a range on the plugin can pull in a version whose requirement no longer matches, and npm install then fails with an ERESOLVE peer dependency error. New apps from knext create --builder vinext pin the plugin exactly for this reason. If an existing app hits that error, set both to the versions above.

Leaving out oxc-transform-react fails the build outright (not a silent no-op): @vitejs/plugin-react errors with "React Compiler requires the optional oxc-transform-react package" the moment react: { compiler: true } is set without it installed.

This is the same option and the same four packages on both vinext runtimes (runtime: 'bun' and runtime: 'node').

Measured conditions

Measured on knext's default target (official adapter, build: 'turbopack', runtime: 'bun'), one small app with a single eligible Client Component (a filter/sort list), one CI runner, next build only (no deploy/cold-start numbers — see the caveat above for why those are unaffected):

No measurable difference at this scale — the memoization bookkeeping the compiler adds roughly offsets what it removes, for an app this small with no actual expensive re-renders to save. The compiler's benefit scales with how much re-render work a component would otherwise repeat; a small test app is not where that shows up. Treat these numbers as "enabling it here costs nothing measurable," not as the ceiling on what it can do for a larger app.

Known limits

• Next's own "only apply to relevant files" heuristic can skip trivial components — see Eligibility above. If you need to confirm the compiler ran on a specific component, look in a built client chunk for Symbol.for("react.memo_cache_sentinel") being compared (not merely present — React defines the symbol regardless) alongside a cache-indexed array pattern.
• On the vinext target, asking for react: { compiler: true } with an @vitejs/plugin-react older than 6.1 installed is silently ignored — no error, no effect. A missing oxc-transform-react, by contrast, fails the build loudly (see above).
• This page covers knext's own build targets only. React Compiler's own eslint plugin, incremental adoption, and per-component opt-out are the same as in any other React project — see the React Compiler docs for those.