feat: add standalone reactCompiler plugin

[kklem0]

Description

Adds reactCompiler(), a standalone plugin export that runs the Rust React Compiler (oxc-transform-react) on its own, for setups where another plugin already owns JSX and Fast Refresh and react() therefore cannot be added. The motivating case is React Router framework mode: reactRouter() replaces react() (remix-run/react-router#12870) and takes no options (remix-run/react-router#12352), so the compiler has to be composed as a sidecar. reactCompilerPreset already fills that role for the Babel path; this is its native counterpart.

import { reactRouter } from '@react-router/dev/vite'
import { reactCompiler } from '@vitejs/plugin-react'

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

Behavior:

• enforce: 'pre', the same slot as the preset with @rolldown/plugin-babel, so the compiler sees source before framework plugins rewrite route modules (React Router injects "use client" and strips exports in a shape the compiler bails on when it runs later).
• Client environments only via applyToEnvironment, mirroring the preset's applyToEnvironmentHook.
• jsx: 'preserve', so JSX lowering stays with whatever owns it. The transform still removes TypeScript syntax, which is fine in the pre slot.
• The same code pre-filter as the preset, applied as a rolldown hook filter, plus include/exclude with the main plugin's defaults. Accepts the same React Compiler options as the compiler option (compilationMode, target, ...).
• Implemented by threading a host discriminator through the existing internal createReactCompilerPlugin, so react({ compiler }) and reactCompiler() share one code path. The react({ compiler }) behavior is unchanged.

Included:

• README section under "Rust React Compiler", carrying over the experimental status.
• Unit tests for the standalone plugin, and tests for the react({ compiler: true }) transform, which had none.
• playground/compiler-standalone, mirroring playground/compiler with the native standalone plugin in place of the Babel preset, asserting compiled output in both serve and build mode.

An equivalent in-house plugin is running in production in a React Router framework-mode app; this PR folds it into the existing implementation so it does not have to be maintained downstream.

[ArnaudBarre]

@pcattori where are you on the "don't vendor the react-plugin" side? It would be good to allow react-router users to not run a full Babel transformation for their apps

[kklem0]

@pcattori where are you on the "don't vendor the react-plugin" side? It would be good to allow react-router users to not run a full Babel transformation for their apps

what's your opinion on merging this? All other solutions seem very hacky and I feel like it's a very small change to this project that would benefit a lot.

[ArnaudBarre]

Having jsx: preserve will break tools that allow navigation back to the editor. Does react-router breaks if JSX is already transformed and fast refresh applied?

From what I remember, react router was mostly 'forking' the runtime part of fast refresh so maybe an idea could be to have an option in the plugin to not inject in the runtime? It would be better than exposing another plugin IMO