Depuis deux ans, la chaîne d'outils JavaScript se réécrit petit à petit en Rust : Vite s'appuie sur Rolldown, Turbopack a remplacé Webpack chez Next.js, et TypeScript prépare sa propre migration native. Un projet va plus loin que les autres en visant directement ESLint et Prettier, les deux piliers les plus lents (et les plus universels) de ton quotidien de développeur : Oxc, porté par VoidZero, la société d'Evan You (le créateur de Vue et de Vite).

Oxc regroupe un parseur, un transformeur, un resolver, un minifieur, un linter (Oxlint) et un formateur (Oxfmt), tous écrits en Rust et pensés pour remplacer les briques historiques sans réécrire tes projets. En 2026, deux étapes importantes ont fait basculer le projet du statut de curiosité à celui d'option sérieuse pour la production : Oxfmt est passé en bêta le 24 février, et Oxlint a ouvert son système de plugins JavaScript en alpha le 11 mars. Voici ce que ça change concrètement, et comment migrer sans tout casser.

L'enjeu n'est pas seulement une question de confort local. Sur un monorepo de plusieurs milliers de fichiers, un eslint . ou un prettier --check . peut représenter plusieurs minutes de pipeline CI, répétées à chaque pull request. Gagner un facteur 10 ou 50 sur ces étapes libère du temps de build, réduit la facture d'infrastructure CI et raccourcit la boucle de feedback des développeurs — un argument qui pèse autant que le confort d'écriture au quotidien.

Oxlint : la promesse d'un ESLint 50 à 100 fois plus rapide

Oxlint n'est pas nouveau : le linter existe depuis plusieurs années et a déjà convaincu une partie de l'écosystème grâce à des benchmarks impressionnants, entre 50 et 100 fois plus rapide qu'ESLint selon les projets testés. Sa force vient de son moteur de règles écrit en Rust, qui embarque aujourd'hui plusieurs centaines de règles natives (au-delà de 690 selon la documentation officielle), couvrant l'essentiel de ce que proposent ESLint core, les plugins React, Unicorn, Import ou encore les règles de sécurité les plus courantes.

La limite historique d'Oxlint restait l'écosystème de plugins : impossible d'utiliser tes règles ESLint maison ou certains plugins tiers, puisque tout devait être réimplémenté en Rust par l'équipe du projet. C'est ce verrou qui a sauté en mars 2026 avec l'arrivée des JS Plugins en alpha : Oxlint peut désormais charger des règles de lint écrites directement en JavaScript, avec une API compatible ESLint v9+. L'équipe du projet estime que cette avancée permet à environ 80 % des utilisateurs d'ESLint de basculer sur Oxlint et de voir leur configuration « simplement fonctionner ».

Ce qui ne marche pas encore

Le mot « alpha » n'est pas cosmétique : les plugins JS tournent aujourd'hui plus lentement que les règles Rust natives (l'équipe travaille justement à réduire cet écart), certaines API ESLint avancées ne sont pas encore couvertes, et les plugins qui manipulent finement l'arbre de syntaxe (AST) via des utilitaires très spécifiques à ESLint peuvent nécessiter des ajustements. Pour un projet avec une configuration ESLint classique (règles de style, React Hooks, imports, accessibilité), la bascule est en revanche déjà réaliste. Dans les cas plus complexes, rien n'empêche de faire tourner Oxlint et ESLint côte à côte : tu gagnes déjà la majorité du temps de lint sur les règles couvertes, sans attendre que les 20 % restants soient portés.

Oxfmt : Prettier en Rust, avec 100 % de conformité

Le formateur Oxfmt a franchi une étape symbolique en passant en bêta le 24 février 2026. Le chiffre qui compte le plus pour l'adoption : Oxfmt annonce désormais réussir 100 % des tests de conformité JavaScript et TypeScript de Prettier, ce qui signifie qu'il produit exactement le même résultat que Prettier sur ces deux langages dans l'immense majorité des cas. Côté performance, le projet revendique plus de 30 fois la vitesse de Prettier, et environ 3 fois celle de Biome, sur un run initial sans cache. Oxfmt a aussi élargi son périmètre bien au-delà du JS/TS : il formate désormais JSON, JSONC, JSON5, YAML, TOML, HTML, Vue, Angular, CSS, SCSS, Less, Markdown, MDX, GraphQL et même Handlebars/Ember, avec un tri d'imports intégré et un support Tailwind CSS. Plusieurs projets de poids ont déjà basculé dessus, dont le cœur de Vue.js, Turborepo et Sentry pour JavaScript — un signal fort que la conformité tient aussi sur des bases de code volumineuses et hétérogènes.

Migrer sans tout casser : la stratégie incrémentale

Tu n'as pas besoin de choisir entre « tout ESLint » et « tout Oxlint » du jour au lendemain. Le paquet officiel eslint-plugin-oxlint est fait pour ça : il désactive automatiquement, dans ta configuration ESLint, toutes les règles déjà couvertes par Oxlint. Tu peux ainsi laisser Oxlint traiter le gros du volume en quelques millisecondes, et ne garder ESLint que pour les règles maison ou les plugins non encore portés.

// Installation des deux outils
npm install --save-dev oxlint eslint-plugin-oxlint

// eslint.config.js
import oxlint from 'eslint-plugin-oxlint';

export default [
  // ... ta configuration ESLint existante
  // Doit rester en dernier : désactive les règles déjà gérées par Oxlint
  ...oxlint.configs['flat/recommended'],
];

Ensuite, tu ajoutes Oxlint à tes scripts, en le faisant tourner avant (ou en parallèle de) ESLint :

// package.json
{
  "scripts": {
    "lint": "oxlint . && eslint .",
    "format": "oxfmt ."
  }
}

Pour aller plus loin, un fichier .oxlintrc.json te permet d'activer les catégories de règles utiles à ton stack (React, TypeScript, imports, accessibilité) :

// .oxlintrc.json
{
  "plugins": ["react", "typescript", "import", "jsx-a11y"],
  "rules": {
    // Tu peux surcharger des règles précises si besoin
    "no-unused-vars": "warn"
  }
}

Côté formatage, la migration est plus simple : Oxfmt lit ta configuration Prettier existante (.prettierrc) et vise le même résultat. Le plus prudent reste de lancer Oxfmt sur une branche dédiée, de vérifier le diff produit sur l'ensemble du dépôt, puis de remplacer la commande prettier --write par oxfmt dans tes hooks de pre-commit et ta CI une fois le résultat validé.

Oxc face à Biome : deux paris différents

Il est légitime de se demander où Oxc laisse Biome, l'autre grand outil « tout-en-un » écrit en Rust. Biome a un an d'avance en maturité : la version 2.4, sortie début 2026, ajoute le lint et le formatage de CSS et GraphQL embarqués directement dans des fichiers JS/TS, et le paquet dépasse 8,8 millions de téléchargements hebdomadaires sur npm. C'est un projet unifié, avec un seul binaire, une seule configuration, et un typage des règles de lint déjà bien installé.

Oxc fait un pari différent : plutôt qu'un outil monolithique, c'est une collection de briques indépendantes (parseur, linter, formateur, minifieur, resolver) que tu peux adopter séparément — tu peux très bien garder ton ESLint actuel et n'ajouter qu'Oxfmt, ou l'inverse. Cette modularité, combinée à l'arrivée des plugins JS, en fait une option pertinente si ta priorité est d'accélérer un existant volumineux sans réécrire toute ta configuration de lint d'un coup. Biome reste préférable si tu démarres un projet de zéro et veux un outil unique dès le départ.

Ce qu'il faut retenir

Pour un projet déjà en place, la voie la plus sûre en 2026 consiste à installer oxlint et eslint-plugin-oxlint en parallèle d'ESLint, à mesurer le gain de temps sur ta CI (souvent spectaculaire dès les premiers milliers de fichiers), puis à tester Oxfmt sur une branche pour comparer le diff avec ta sortie Prettier actuelle. Si ta configuration de lint est standard (pas de plugin ESLint très exotique), tu peux probablement basculer l'essentiel dès aujourd'hui ; si tu dépends de règles maison complexes, garde un œil sur l'avancement des JS Plugins avant de couper complètement ESLint. Dans tous les cas, le temps que tu gagnes sur chaque lint et chaque format en CI se compte désormais en dizaines de secondes économisées à chaque exécution — un gain qui s'accumule vite sur des centaines de pull requests par mois.

Oxlint et Oxfmt : migrer d'ESLint/Prettier vers Rust en 2026