Un aperçu du JavaScript Oxidation Compiler

Oxc, le JavaScript Oxidation Compiler, est un ensemble d’outils JavaScript et TypeScript hautes performances écrits en Rust, construits sur un parser et un AST partagés, de sorte que le linter, le formateur, le transformeur, le minifieur et le resolver ne réanalysent jamais votre code chacun de leur côté.

Si vous avez déjà lancé un linting sur un gros monorepo, filé vous faire un café et découvert à votre retour que ça tournait toujours, vous savez déjà pourquoi une réécriture en Rust de la chaîne d’outils JavaScript a suscité autant d’attention. Cette attente, multipliée par chaque développeur et chaque job de CI, constitue l’essentiel de la raison d’être d’Oxc.

C’est la couche compilateur qui sous-tend la chaîne d’outils de VoidZero, et depuis Vite 8, c’est la machinerie qui effectue le véritable travail sur le langage au sein de chaque build Vite.

Si votre pipeline ESLint/Babel/Prettier est lent et que vous suivez la vague de l’outillage en Rust (esbuild, SWC, Biome, Oxc), la vraie question n’est pas « Oxc est-il rapide ? ». C’est « quelles briques sont prêtes pour la production aujourd’hui, et comment se positionnent-elles face à ce que j’utilise déjà ? ». Cet article y répond : ce qu’est Oxc, ce qu’il contient, ce que vous pouvez adopter sans risque dès maintenant, et comment il se compare aux alternatives.

Qu’est-ce qu’Oxc, le JavaScript Oxidation Compiler ?

Oxc est une suite d’outils JavaScript et TypeScript nativement écrits en Rust, qui partagent un unique parser et un unique AST : le comportement reste ainsi cohérent et aucun outil ne duplique le travail d’analyse. Le nom fait un clin d’œil à Rust : la rouille (rust) est ce que devient le métal lorsqu’il s’oxyde. La rapidité est ici traitée comme un livrable que le projet doit fournir, et non comme un agréable effet de bord, en partant du principe qu’un linter plus rapide signifie une boucle édition-vérification plus serrée en local et une facture de CI plus légère.

Ce qui rend Oxc important au-delà de ses propres CLI, c’est qu’il constitue le compilateur sous la stack Vite moderne. Rolldown est un bundler écrit en Rust, et il délègue à Oxc le travail au niveau du langage, parsing et minification compris. À partir de Vite 8, les trois couches sont développées par des équipes travaillant de concert : Vite comme outil de build, Rolldown comme bundler, et Oxc comme compilateur sous-jacent aux deux. Ainsi, même les développeurs qui n’installent jamais un paquet Oxc exécutent son parser et son transformeur à chaque build.

Il y a aussi un contexte de gouvernance à connaître avant de miser un pipeline dessus. Le 4 juin 2026, Cloudflare a annoncé le rachat de VoidZero, l’entreprise open source qui maintient Vite et son outillage, Oxc inclus. Les deux parties affirment que les projets restent open source et neutres vis-à-vis des éditeurs, Vite, Vitest, Rolldown, Oxc et Vite+ demeurant tous sous licence MIT, et Cloudflare a doté d’un million de dollars un fonds indépendant destiné aux mainteneurs et contributeurs de Vite. VoidZero avait elle-même été créée en 2023 par Evan You, le créateur de Vue.js.

Les composants et ce que chacun remplace

Oxc est distribué sous forme de briques distinctes et composables : vous pouvez donc en adopter une sans les autres. Chacune cible un acteur historique lent, écrit en JavaScript :

Le parser est le point d’ancrage. Tous les autres composants consomment sa sortie, ce qui permet à Oxc de se présenter comme une chaîne d’outils unique plutôt que comme six outils qui se trouvent, par hasard, être écrits en Rust.

Pourquoi Oxc est-il rapide ?

La rapidité d’Oxc découle de son architecture, pas de micro-optimisations. Trois choix font l’essentiel du travail. Premièrement, il s’agit de Rust compilé plutôt que de JavaScript interprété : les chemins critiques s’exécutent à la vitesse du natif et évitent les pauses du ramasse-miettes. Deuxièmement, tous les outils opèrent sur un unique AST partagé, ce qui élimine les réanalyses redondantes qui se produisent lorsque ESLint, Prettier et Babel parsent chacun séparément le même fichier. Troisièmement, les nœuds de l’AST sont alloués dans une arène mémoire pour un nettoyage en masse peu coûteux, et l’analyse est parallélisée sur les cœurs du processeur.

Le gain est mesuré, mais les chiffres sont les benchmarks du projet lui-même : à prendre comme tels. VoidZero annonce Oxlint 50 à 100 fois plus rapide qu’ESLint, Oxfmt à 30× ou plus le débit de Prettier et entre 2× et 3× celui de Biome lors d’une première exécution sans cache, et Rolldown avec des builds jusqu’à 10 à 30 fois plus rapides que Rollup. Le chiffre pour Biome est une fourchette parce que les sources d’Oxc elles-mêmes divergent : la documentation du formateur indique 2×, l’annonce de la beta 3×. Des benchmarks différents sur des machines différentes donneront des résultats différents : l’ordre de grandeur du gain est réel, le multiplicateur exact relève du marketing jusqu’à ce que vous le mesuriez sur votre propre dépôt.

Qu’est-ce qui est prêt pour la production dans Oxc aujourd’hui ?

La maturité dans Oxc dépend de la façon dont vous consommez chaque outil. Oxlint et le parser sont réellement de qualité production en autonome ; le transformeur et le minifieur sont en pré-1.0 en tant que CLI mais tournent déjà en production à l’intérieur de Rolldown et de Vite 8 ; Oxfmt est en beta.

Oxlint sort nettement du lot. Il a livré une version 1.0 stable en juin 2025, avec Shopify, Airbnb et Mercedes-Benz cités dans les notes de version comme utilisateurs en production, et il est désormais sur une ligne 1.x avec 844 règles intégrées. Oxlint fait aussi du linting tenant compte des types : le backend tsgolint branche le système de types de TypeScript lui-même sur la CLI et le format de configuration d’Oxlint, et couvre 59 des 61 règles type-aware fournies par typescript-eslint. Les réserves, en toute honnêteté : c’est opt-in, cela nécessite l’installation du paquet distinct oxlint-tsgolint aux côtés d’Oxlint, et les numéros de version de ce paquet suivent la version de TypeScript sur laquelle il est construit plutôt que celle d’Oxlint : les deux évoluent donc selon des calendriers différents. L’équipe a également fermé la porte aux règles situées hors de l’ensemble de typescript-eslint le temps de travailler sur la couverture et les performances, ce qui exclut pour l’instant les règles type-aware personnalisées.

Ne lisez pas « le transformeur et le minifieur sont en pré-1.0 » comme « pas prêts pour la production ». Les deux tournent déjà sous chaque build Vite 8. Le guide de migration vers Vite 8 détaille la répartition des tâches : Oxc a repris à esbuild la transformation JavaScript et la minification JavaScript, tandis que Lightning CSS est devenu la solution par défaut pour minifier le CSS. Oxfmt, de son côté, est passé d’alpha à beta et valide désormais l’intégralité de la suite de conformité JavaScript et TypeScript de Prettier, mais npm l’étiquette toujours comme Beta : c’est donc un pilote, pas encore un remplacement complet de Prettier.

Comment Oxc se compare à SWC et Biome

L’erreur de comparaison la plus fréquente consiste à opposer Oxc à SWC sur la rapidité. Ils occupent des couches différentes. SWC est une plateforme de compilation que les frameworks embarquent : Next.js maîtrise sa jonction avec SWC, et vous n’avez pas intérêt à l’arracher pour courir après un graphique de benchmark. Le transformeur d’Oxc concurrence SWC et Babel, mais SWC n’a ni linter ni formateur first-party : Oxlint concurrence donc ESLint et Biome, pas SWC. Biome est le rival le plus proche : un outil Rust qui fait à la fois le linting et le formatage dans un seul binaire, là où Oxc conserve Oxlint et Oxfmt comme briques distinctes et composables.

Dans ces conditions, la démarche pragmatique consiste à adopter Oxlint dès maintenant et à observer le reste. Exécutez-le comme première passe rapide en CI tout en conservant ESLint pour les règles et plugins qu’il ne couvre pas encore :

{
  "scripts": {
    "lint:fast": "oxlint",
    "lint": "oxlint && eslint ."
  }
}

Pour limiter les chevauchements, la documentation renvoie à @oxlint/migrate pour convertir une configuration ESLint existante, ainsi qu’à eslint-plugin-oxlint pour désactiver les règles déjà prises en charge par Oxlint. Vous obtenez ainsi le gain de vitesse sur le chemin rapide sans renoncer à la couverture d’ESLint lors de l’exécution complète.

Oxc est passé du statut de « projet Rust prometteur » à celui d’infrastructure dont dépendent déjà des millions de builds, mais pas de façon uniforme sur l’ensemble de son périmètre. Commencez par Oxlint (stable, rapide et peu risqué à côté de votre linter actuel), testez Oxfmt sur une branche pour examiner le diff, et laissez le transformeur et le minifieur vous parvenir via Vite 8 plutôt que de les adopter en autonome. Réévaluez les briques en pré-1.0 au fur et à mesure de leur passage en stable ; la trajectoire est suffisamment claire pour bâtir un plan dessus.

FAQ

Puis-je utiliser Oxlint et ESLint ensemble, ou dois-je choisir l'un des deux ?

Vous pouvez utiliser les deux, et c'est même la voie d'adoption recommandée. Utilisez Oxlint comme première passe rapide en CI et conservez ESLint pour les règles et plugins qu'Oxlint ne couvre pas encore. La documentation d'Oxc renvoie à '@oxlint/migrate' pour convertir une configuration ESLint existante et à 'eslint-plugin-oxlint' pour désactiver les règles ESLint déjà prises en charge par Oxlint, ce qui supprime le travail en double pendant que vous exécutez les deux linters.

Oxc remplace-t-il SWC, et devrais-je retirer SWC de Next.js pour l'utiliser ?

Non. Le transformeur d'Oxc concurrence SWC et Babel, mais vous ne devriez pas arracher SWC d'un framework qui l'embarque, comme Next.js, pour courir après un benchmark. SWC est une plateforme de compilation que les frameworks pilotent en interne, et SWC n'a ni linter ni formateur first-party : Oxlint concurrence donc ESLint et Biome plutôt que SWC. La surface d'adoption sûre est Oxlint, pas le remplacement du compilateur intégré d'un framework.

Quelle est la différence entre Oxc et Biome ?

Biome est un binaire Rust unique qui assure à la fois le linting et le formatage, tandis qu'Oxc conserve son linter (Oxlint) et son formateur (Oxfmt) comme briques distinctes et composables, adoptables indépendamment. Oxc est aussi plus large : il inclut un parser, un transformeur, un minifieur et un resolver qui font tourner Rolldown et Vite 8, là où Biome se concentre sur la couche linting et formatage. Sur une première exécution sans cache, les benchmarks de VoidZero situent Oxfmt à environ 2 à 3 fois plus rapide que Biome ; la documentation d'Oxfmt et l'annonce de la beta citent des chiffres différents pour cette comparaison.

Le rachat de VoidZero par Cloudflare remet-il en cause le caractère open source d'Oxc ?

Non. Cloudflare a acquis VoidZero le 4 juin 2026, et les deux entreprises affirment que les projets restent open source et neutres vis-à-vis des éditeurs. Vite, Vitest, Rolldown, Oxc et Vite+ demeurent sous licence MIT, et Cloudflare a engagé 1 million de dollars dans un nouveau fonds indépendant pour l'écosystème Vite, destiné aux mainteneurs et contributeurs sans affiliation avec VoidZero ni avec Cloudflare. La licence MIT signifie que les forks et usages existants ne sont pas affectés, quel que soit le propriétaire.