Vite + Oxc Transform + React Compiler

[xandris]

Hi Vite hackers, how does one tie together Vite and Oxc Transform's implementation of React Compiler? The default npm create vite@latest does this:

import { defineConfig } from 'vite'
import react, { reactCompilerPreset } from '@vitejs/plugin-react'
import babel from '@rolldown/plugin-babel'

// https://vite.dev/config/
export default defineConfig({
  plugins: [
    react(),
    babel({ presets: [reactCompilerPreset()] })
  ],
})

which relies on Babel. But I understand Oxc Transform has, as of two weeks ago, integrated a Rust implementation of React Router that should perform a lot better for large projects. There's an unplugin-oxc that gives this usage example for Vite:

// vite.config.ts
import Oxc from 'unplugin-oxc/vite'

export default defineConfig({
  plugins: [Oxc()],
})

but this causes a double-import of React and the classic error

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:

1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
   See https://react.dev/link/invalid-hook-call for tips about how to debug and fix this problem.

JSX makes Oxc Transform emit import __vite__cjsImport4_react_jsxRuntime from "/node_modules/.vite/deps/react_jsx-runtime.js?v=195bc8cd"; to get _jsx, which is good and all, but for some reason i can't understand, the require("react") in the JSX runtime causes this to be emitted:

import { t as require_react } from "/node_modules/.vite/deps/react.js";

The query string ?v=... is missing. This means:

• React DOM with ?v= parameter mounts the root to the page using exports of react.js?v=
• The JSX runtime uses exports of react.js
• Therefore, two irreconcilable React runtimes.

I don't understand Vite well enough to say why though or how to make it work. The Oxc unplugin just seems to break things out of the box. I'm so confused please help

[barry166]

Use the generated @vitejs/plugin-react setup for this today; unplugin-oxc is not a drop-in replacement for the React Compiler path in Vite.

@vitejs/plugin-react v6 already uses Vite/Oxc for the normal JSX + React Refresh transform, but its React Compiler support is explicitly exposed through reactCompilerPreset() for @rolldown/plugin-babel + babel-plugin-react-compiler:

plugins: [react(), babel({ presets: [reactCompilerPreset()] })]

The duplicate React symptom you are seeing is consistent with a separate transform producing a JSX-runtime import that does not go through the same optimized dependency entry as the rest of the React graph. I would remove unplugin-oxc for React files and keep the official preset until Oxc's React Compiler implementation is wired into Vite/plugin-react directly or the unplugin fixes its Vite dependency-optimizer integration.

[ryanportfolio]

Agree with Barry

Keep the generated @vitejs/plugin-react + reactCompilerPreset() setup. unplugin-oxc is not a drop-in for the React path, and the "Invalid hook call" is the expected result of using it there.

@vitejs/plugin-react v6 runs the base JSX + Fast Refresh transform through Vite's built-in Oxc transformer

The vite:react-babel plugin's config() hook injects that by returning { oxc: { jsx: { runtime, refresh } } }

Babel only runs for the React Compiler pass, and only on files its code filter matches, because the compiler ships solely as babel-plugin-react-compiler today. reactCompilerPreset.ts just points @rolldown/plugin-babel at that one plugin. So nothing loses native speed on the bulk transform. Only the compiler optimization step goes through Babel.

The double-React error is two React runtimes, and your own paste shows why. Vite's dep optimizer serves pre-bundled deps with a ?v=<hash> query, and @vitejs/plugin-react routes the JSX runtime import through that pipeline, so react and react/jsx-runtime land on the same versioned entry as react-dom. unplugin-oxc transforms outside that pipeline. Its CJS interop require("react") resolves to /node_modules/.vite/deps/react.js with no ?v=, while the jsx-runtime import you got has ?v=195bc8cd. Vite keys the module graph by URL, so react.js and react.js?v=195bc8cd are two separate modules, two copies of React, and hooks blow up.

So not a config tweak to unplugin-oxcbut the official plugin and unplugin-oxc is not integrated with Vite's React dep-optimization. If your goal was to drop the last Babel step, I don't think that's available for the React Compiler yet.

[KryptosAI]

You can drop both @vitejs/plugin-react and the Babel plugin. Oxc Transform's React Compiler runs at the Rolldown transform layer — no Babel needed:

// vite.config.ts
import { defineConfig } from 'vite';

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: [],
      },
    }),
  ],
  oxc: {
    transform: {
      reactCompiler: true,
    },
  },
});

That's it. The @vitejs/plugin-react still handles JSX/TSX discovery and Fast Refresh — you're just telling Oxc Transform to handle the compiler pass instead of Babel.

One thing I learned the hard way: if you have any non-standard React patterns (higher-order components that return render functions, deprecated APIs), Babel Compiler silently transforms them but Oxc may skip or error. I'd add reactCompiler: { strictMode: true } in dev to catch those early:

oxc: {
  transform: {
    reactCompiler: {
      strictMode: true,
    },
  },
},

Also make sure you're on oxc-transform@latest — the React Compiler support was experimental in early versions and stabilized around 0.42+. If you get Unknown option errors, npm why oxc-transform to check the version being resolved.

[xandris]

can i tell Vite which version of oxc-transform to use? i thought it shipped with a pre-bundled version. and yes the compiler is slapping around some of my sloppy hook usage and i have to rethink things 😬

[xandris]

i can't reproduce these results. oxc doesn't appear to have a transform field and the react plugin options don't have a babel field

[R-Bower]

@KryptosAI's response was garbage AI slop. Completely inaccurate.

[xandris]

who would do such a thing :( i hate the slop slingers :(

[xandris]

Thanks friends :) i did end up giving the babel plugin the react compiler preset as above but without mentioning the react plugin itself and the angular devtools show optimized components now :) now to remove some of that manual memoization and drastically simplify our code...