Remplacer ESLint et Prettier par Biome : vitesse contre la règle des hooks dont vous avez encore besoin

Les publications de marketing vendent un binaire Rust, une seule configuration, et des gains allant de 20 à 50 fois. Un test en quatre itinéraires a ensuite été effectué, suivi du décompte des diagnostics que Biome ne prend pas en charge.

Un seul binaire contre des tas de plugins : le temps d’exécution a diminué, mais la couverture pour une règle importante n’a pas évolué.

Vérifiez le fichier package.json.

Faites le bilan des dépendances liées aux outils de vérification. Les projets qui incluent encore eslint, prettier, eslint-config-prettier, eslint-plugin-react-hooks, ainsi qu’un plugin de parsing, paient une taxe silencieuse à chaque mise à jour. Biome se présente comme un seul exécutable permettant le formatage, la vérification et l’organisation des imports.

Biome a été ajouté à côté de l’outilchain ESLint existant dans ce laboratoire. Les deux pipelines ont été chronométrés. ESLint a ensuite été supprimé. Un diagnostic dépendant ne disposait d’aucune équivalence fiable avec Biome. Le pipeline a donné un résultat positif, et la classe de bug que ce diagnostic utilisait pour bloquer a réapparu sur une branche fonctionnelle.

La branche a de nouveau activé un websocket lors du changement de thème — un classique problème de dépendance aux effets visuels. Biome est resté silencieux.

La phrase que Biome publie réellement

Officiellement, Biome formate le code avec une concordance d’environ 97 % avec Prettier et effectue des vérifications de conformité grâce à un vaste ensemble de règles inspirées d’ESLint et de typescript-eslint. Les paramètres se trouvent dans biome.json. L’utilisation quotidienne s’effectue via l’instruction pnpm exec biome check --write.

Ce que les articles spectaculaires omettent : des plugins obscurs ou des règles internes peuvent encore manquer. Il faut soit conserver ESLint pour ces cas, soit retranscrire la logique correspondante.

La vitesse est facile à apprécier. L’absence de couverture, en revanche, représente un vrai problème.

Les temps réellement enregistrés

Le laboratoire a combiné TypeScript, React ainsi que quelques modules serveur — environ soixante fichiers hors node_modules. Instant Navigations a été désactivé, de sorte que seul le vérificateur a été mesuré.

pnpm exec eslint . --max-warnings=0
pnpm exec prettier --check .
pnpm exec biome check .

Trois exécutions chacun ; valeurs médianes :

• ESLint seul : 4,1 s
• Prettier --check : 1,6 s
• ESLint puis Prettier : 5,7 s
• Biome check : 0,22 s

Ce n’est même pas près de 50 fois plus rapide. Par rapport à la paire d’outils utilisés séquentiellement, c’est environ 26 fois plus rapide sur un petit projet. Les tests de blog citent souvent des projets avec environ 10 000 fichiers. Cette mesure utilise l’application qui est réellement déployée. La tendance est cohérente ; le multiplicateur exagéré, lui, ne l’est pas.

Une vérification fraîche et Prettier étaient en désaccord pour deux fichiers : un long enrobage de propriété JSX à l’intérieur de InvoiceRow. L’enrobage utilisé par Biome a été conservé. Le chiffre de 97 % est exact ; les 3 % restants ne deviennent un problème que si une équipe examine chaque fichier individuellement.

Comment le voir sur votre machine

pnpm add -D --save-exact @biomejs/biome
pnpm exec biome init

Un fichier biome.json apparaît. Exécutez Biome une fois tant qu’ESLint est encore présent. Ne supprimez rien avant d’avoir un inventaire écrit des erreurs ESLint que Biome ne signale pas.

pnpm exec eslint . -f unix > /tmp/eslint.txt
pnpm exec biome check --reporter=json > /tmp/biome.json

Une comparaison manuelle a montré que la plupart des éléments de recommended se chevauchaient. L’écart notable :

react-hooks/exhaustive-deps

Biome inclut des vérifications liées aux hooks. Elles ne correspondaient pas à l’avertissement précis qui concernait auparavant un effet socket. Lorsque le CI a supprimé cette règle, une erreur liée au changement de thème est passée inaperçue.

ESLint a généré un résultat pour un seul plugin :

{
  "scripts": {
    "lint": "biome check . && eslint app --plugin react-hooks --rule 'react-hooks/exhaustive-deps:error'"
  }
}

Incompétent. Transparent. Utiliser deux outils constitue un compromis raisonnable et moderne lorsque la règle manquante a un nom. Conserver un arbre ESLint complet « au cas où » est généralement du gaspillage.

Vérifiez le fonctionnement de l’éditeur le même soir. Le serveur linguistique de Biome a remplacé deux extensions ; soudain, l’avertissement lié aux hooks n’apparaissait plus qu’en environnement CI — pire encore localement, à moins que l’extension ESLint ne reste activée pour cette règle précise. Préférez le voir dans /settings plutôt que de l’ découvrir lors de la compilation du matin.

Qu’est-ce qui est vraiment plus rapide

Biome parcourt l’arborescence en tant que processus natif unique. ESLint, lui, repose sur Node et des plugins, souvent suivis de Prettier. Avec soixante fichiers, le chargement des plugins consomme une grande partie des 4,1 secondes nécessaires. Avec des milliers de fichiers, c’est le parcours lui-même qui domine, et des ratios propres à l’échelle commerciale apparaissent.

Biome 2 propose un contrôle de qualité basé sur les types, mais il ne couvre pas l’ensemble des fonctionnalités de typescript-eslint. Si l’intégration continue permet encore d’utiliser parserOptions.project, évaluez ce processus séparément — c’est le mode ESLint le plus gourmand en ressources. On constate des lacunes par rapport aux anciennes options no-unsafe-*.

Désactiver l’analyse tenant compte du projet, voir le temps d’exécution de l’intégration continue passer de ~90 secondes à ~8 secondes, et attribuer ce gain à Biome est trompeur, car il s’agit simplement du retrait de la phase d’analyse basée sur les types. Dites-le à haute voix lorsque cela se produit.

Le bilan détaillé

Durée du pipeline : de 5,7 secondes à 0,22 seconde ici. Les monorepos ressentent le plus fortement cet avantage. Les petites applications bénéficient principalement d’un exécution plus rapide sur ordinateur portable.

Règles : une vérification dépendante a disparu ; ESLint reste actif pour ce chemin.

Problèmes de formatage : deux enveloppes JSX ; cela peut être corrigé.

Éditeur : deux extensions sont devenues une seule, puis une autre est réapparue — le bilan est à peu près équilibré, avec une vérification via la ligne de commande plus rapide.

Attention : une exécution avec Biome en mode vert ne signifie pas pour autant que l’arbre des hooks est également vert. Les demandes de fusion doivent indiquer quel utilisateur a marqué le fichier.

Laissez-le actif, ou arrêtez la phase nocturne

Les dépôts Greenfield peuvent adopter Biome dès ce soir pour le formatage ainsi que les vérifications de base, en omettant complètement Prettier.

Les arbres hérités doivent être exécutés en parallèle pendant environ une semaine. Conservez ESLint uniquement pour les plugins nommés. Supprimez les configurations inutilisées, et non seulement l’étape de CI.

Persistez avec ESLint lorsque des règles personnalisées constituent réellement le produit — et notez ces règles par écrit. « Peut-être avons-nous besoin de plugins » n’est pas une liste d’inventaire.

N’abandonnez jamais exhaustive-deps simplement parce que Biome est rapide. Un changement de thème montrera pourquoi cette règle existait.

Mises en garde à mentionner clairement

0,22 s contre 5,7 s correspond à soixante fichiers sur un ordinateur portable — pas à un corpus de 10 000 fichiers, ni à une prétention de 56 fois plus rapide.

L’écart des crochets dépend de la configuration et de la structure du biome cette nuit-là. Exécutez à nouveau biome rage et examinez les diagnostics actuels des crochets avant de considérer le trou comme permanent ; les identifiants changent d’une version à l’autre.

Les inventaires des plugins diffèrent. Si le tri par ordre d’importation via eslint-plugin-import est le seul problème persistant, essayez l’outil organize-imports de Biome pendant une semaine.

Mettez à jour les deux outils. Énumérez les problèmes trouvés par ESLint qui persistent après avoir nettoyé avec Biome.

Cette énumération est le travail de migration. Les solutions restantes permettent d’utiliser un script de vérification double avec des responsabilités clairement définies.

Lorsque CI est passé en vert et que la connexion socket a été rétablie

ESLint plus Prettier ont été remplacés par Biome. Temps de vérification de soixante fichiers : 0,22 s contre 5,7 s. Une branche a été fusionnée. Le changement de thème a rétabli une connexion WebSocket totale. react-hooks/exhaustive-deps bloquait auparavant ce type de configuration ; Biome ne génère pas le signal correspondant.

Réponse inadéquate. Mettez le socket en pause jusqu’à ce que « la migration soit terminée ». Les clients perdent alors la représentation en temps réel.

Réponse plus appropriée. Biome gère le format et les vérifications de base ; ESLint reste utilisé pour un seul plugin situé sous app.

{
  "scripts": {
    "lint": "biome check . && eslint app --plugin react-hooks --rule 'react-hooks/exhaustive-deps:error'"
  }
}

Deux approches sont fiables lorsque la règle absente est spécifiée clairement. Deux approches sont inutilement coûteuses lorsque toute la configuration ESLint est conservée. Différences de formatage : deux enveloppes JSX ; la version de Biome est maintenue.

Mesurez sur votre propre projet. Faites une liste des règles exclusivement ESLint après avoir nettoyé le projet avec Biome. Listez d’abord ; utilisez un chronomètre ensuite.

Commandes et résultats de la session de laboratoire

Versions utilisées avant le démarrage : Node 24, TypeScript 7, Next 16.3. Conservez-les dans une note de laboratoire afin que la prochaine session ne repose pas sur des suppositions.

node -v
pnpm exec tsc -v
pnpm exec next --version

Placez ces trois lignes en haut de la note. Si une version majeure ne correspond pas au guide suivi, arrêtez-vous — les commandes suivantes pourraient induire en erreur de manière discrète.

Prochaine étape : balade sur le réseau :

pnpm exec next dev

Appuyez sur /, /invoices, /invoices/1, /settings, puis à nouveau sur /invoices. Laissez DevTools avec l’option « preserve-log » activée. Capturez l’interface du filtre ainsi que l’URL ; cette paire est utile pour des expériences similaires.

Vérification de type :

pnpm exec tsc --noEmit --pretty false
echo $?

Un code de sortie zéro ne correspond pas à un produit final. Il se contente de préparer le chemin pour des vérifications en temps de exécution.

Ensuite, relancez les commandes de découverte indiquées dans « Comment le voir sur votre machine ». Ne les sautez pas sous prétexte que des chiffres y apparaissent. Une autre machine, la chaleur ambiante ou des onglets Chrome en cours d’utilisation peuvent affecter davantage la mémoire, la durée des vérifications et les temps d’exécution qu’un correctif de framework.

Tenez une entrée d’une ligne pour chaque solution échouée : « J’ai essayé X, mais j’ai toujours obtenu Y. » Les versions, les commandes, les résultats et cette phrase constituent des informations utiles pour poursuivre les recherches. Les captures d’écran destinées au marketing ne le sont pas.

Journal des échecs

La suppression d’ESLint le même jour où Biome est arrivé a réactivé le problème de socket. La restauration d’un seul plugin a permis de retrouver la couverture nécessaire.

Essayer d’imiter le comportement de typescript-eslint adapté aux projets dans Biome 2 a révélé une correspondance partielle. L’ancien groupe no-unsafe-* ne correspondait pas. Prétendre le contraire a cessé de fonctionner.

Un long conflit de formatage des propriétés JSX s’est résolu en acceptant Biome.

Dans l’éditeur, le LSP de Biome a remplacé les extensions Prettier et ESLint. Les avertissements liés aux hooks n’apparaissaient alors que dans les tests CI, ce qui a poussé à conserver l’extension ESLint pour cette règle. Deux extensions restent préférables à cinq.

Liste de vérification avant de supprimer ESLint

• [ ] biome check se termine sans erreur
• [ ] Les règles propres à ESLint sont notées
• [ ] Les plugins nommés sont conservés ou abandonnés consciemment
• [ ] exhaustive-deps dispose d’un équivalent fiable, ou ESLint reste utilisé pour cette fonctionnalité

[ ] Les formats deltas sont examinés calmement, sans réversion paniquée

[ ] Les deux chronomètres ont été pris sur le même arbre

0,22 s contre 5,7 s, soit soixante fichiers. Rémesurez localement. Vérifiez à nouveau les diagnostics des hooks sur le Biome installé avant de considérer l’écart comme définitif.

Note de production de l’application de facturation

CI a enregistré les secondes réelles. Lors d’une démonstration, le changement de thème a provoqué une nouvelle connexion WebSocket car la couverture des hooks avait disparu. Les secondes ne sont pas le produit final — c’est l’agrégat en temps réel.

Préférez un outil de vérification plus lent mais capable de détecter les reconexions plutôt qu’un outil ultra-rapide qui les manque. Combiner Biome à 0,22 s avec un seul plugin ESLint constitue également une bonne solution. Les nouveaux dépôts peuvent commencer avec uniquement Biome et ajouter ESLint une fois qu’une règle a été définie. Les dépôts existants ne gagnent rien avec ce théâtre de la pureté.

Commandes

pnpm exec eslint . --max-warnings=0
pnpm exec prettier --check .
pnpm exec biome check .

Exécuter trois fois ; prendre les valeurs médianes. Enregistrer les résultats d’ESLint, de Prettier ainsi que ceux de Biome. Exporter la sortie d’ESLint au format Unix et cartographier les anomalies que Biome n’a pas détectées. Insérer cette carte dans la demande de fusion ; considérer l’heure comme une note en bas de page.

La différence significative correspond à la règle qui n’a pas de counterpart.

Exercice pour le lecteur sur un arbre réel

Choisir un dépôt fonctionnel, et non un environnement de test isolé. Mesurer le temps d’exécution pour eslint ., prettier --check . et biome check . — trois exécutions chacun. Présenter les valeurs médianes sous forme de tableau, accompagnées du nombre de fichiers.

Créer manuellement la différence entre les règles pour une première étape ; les renommages automatisés induisent souvent en erreur. Énumérer toutes les anomalies détectées par ESLint qui persistent après que Biome ait nettoyé le code. Liste vide → ESLint peut être ignoré. Liste contenant react-hooks/exhaustive-deps ou un plugin personnalisé essentiel au produit → conserver cette partie.

Ouvrez une branche dotée d’un hook dont la dépendance manquante est connue pour être réelle. Vérifiez quel outil signale un problème. C’est à cause de cette branche que la comparaison n’est pas simplement une course contre la montre.

Communiquez la table ainsi que la liste des règles. Évitez les demandes de pull request de type « switched to Biome » qui se contentent de supprimer des packages. La suppression est l’étape finale, et non le premier mouvement.