Le React Compiler passe en Rust dans Vite

Ce qui se passe

L'équipe oxc a publié le 4 août 2026 le support officiel du React Compiler en Rust, dans le paquet oxc-transform-react. La version 6.1.0 de @vitejs/plugin-react l'expose nativement, sous l'étiquette « experimental native React Compiler support ».

L'auteur du billet rapporte avoir basculé la base de code d'Outlyne, un constructeur de sites en React Router de 1 036 fichiers, et en donne les mesures.

Les chiffres, et ce qu'ils ne disent pas

C'est la nuance importante, et l'auteur la pose lui-même : le facteur 17 ne porte que sur la partie compilateur. Tout le reste du build continue de coûter ce qu'il coûtait. Sur ce projet, le gain de bout en bout retombe à 2,4×.

Boshen, qui dirige oxc, reste d'ailleurs plus prudent sur son propre banc d'essai préliminaire :

It is more than 10 times faster than Babel in our preliminary benchmark.

Ce que ça change au-delà de la vitesse

L'argument le plus solide n'est pas le temps de build : c'est que la version Rust suit désormais l'amont, quand la version Babel est une impasse. Trois schémas qui provoquaient un abandon de compilation sont désormais gérés :

• la logique conditionnelle dans un bloc try/catch — un blocage bien connu de la version 1.0 stable ;
• la réassignation d'une prop déstructurée utilisée dans une closure imbriquée ;
• les clés d'objet calculées.

Sur l'application citée, ces corrections font entrer sept fonctions supplémentaires dans le périmètre compilé : cinq grâce au try/catch, deux grâce aux clés calculées.

Deux schémas continuent de provoquer un abandon : un throw depuis l'intérieur d'un bloc try, et les opérateurs d'assignation logique (??=, &&=, ||=).

Bénéfice moins visible mais réel : la cohérence de chaîne d'outils. L'auteur raconte avoir ouvert un ticket erroné chez oxc parce qu'un composant n'était ni optimisé au build ni signalé par le linter — Oxlint utilisait oxc-transform-react 0.145.0 quand son build tournait en 0.144.0. Linter et build sur la même version du compilateur, il n'y a plus d'angle mort où un composant non compilé passe en production.

Comment s'y prendre

Avec @vitejs/plugin-react, sur Vite 8 ou plus, la migration consiste surtout à retirer des choses. Installer le paquet :

npm install -D oxc-transform-react

Puis simplifier la configuration :

// vite.config.js
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react({ compiler: true })],
});

@rolldown/plugin-babel peut alors sortir des dépendances de développement.

Pour une base sur React Router en framework mode, qui utilise son propre plugin Vite, le chemin passe par un plugin minimal dédié :

npm install -D @acusti/vite-plugin-react-compiler

// vite.config.js
import { defineConfig } from "vite";
import reactCompiler from "@acusti/vite-plugin-react-compiler";
import { reactRouter } from "@react-router/dev/vite";

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

On y perd vite-plugin-babel, babel-plugin-react-compiler et @babel/preset-typescript.

À retenir

1. Le paquet à installer est oxc-transform-react ; Vite 8 est requis et le support reste marqué expérimental.
2. Attendez-vous à un gain de bout en bout autour de 2×, pas de 17× — le facteur annoncé ne concerne que l'étape de compilation React.
3. Aligner le linter et le build sur la même version du compilateur vaut probablement autant que la vitesse.

Source : master.dev