Biome : alternative rapide à ESLint et Prettier

Biome : un seul binaire pour formater et linter

La documentation officielle de Biome présente l'outil comme une toolchain web unique : formatage, lint et commande check dans un même binaire écrit en Rust. Pour une équipe qui enchaîne aujourd'hui ESLint, Prettier et leurs plugins TypeScript ou React, la promesse est simple : moins de fichiers de configuration, moins de dépendances npm et des retours plus rapides en local comme en CI.

Biome couvre JavaScript, TypeScript, JSX, TSX, JSON, HTML, CSS et GraphQL. Le site indique une compatibilité d'environ 97 % avec Prettier sur le formatage, avec des règles de lint inspirées d'ESLint et de typescript-eslint. L'intérêt pour une PME ou un freelance n'est pas de remplacer une stack mature du jour au lendemain, mais de tester si un dépôt pilote gagne en simplicité sans perdre les garde-fous essentiels.

Ce que Biome apporte concrètement

Comparaison honnête avec ESLint et Prettier

ESLint reste l'écosystème le plus extensible : des centaines de plugins couvrent React, Vue, accessibilité, imports ou conventions d'équipe très spécifiques. Prettier, de son côté, est devenu la référence de formatage opinionated, avec une intégration editor très répandue.

Biome compresse ces deux rôles dans un seul outil natif. Les gains annoncés côté performance proviennent de l'implémentation Rust et d'une architecture proche de rust-analyzer. Sur un gros dépôt, la différence se ressent surtout dans les boucles locales et les pipelines CI qui relancent lint et format à chaque push.

Les limites sont réelles : toutes les règles ESLint n'ont pas d'équivalent, et la compatibilité Prettier n'est pas totale. Les projets avec des plugins ESLint très spécialisés ou des overrides Prettier fins devront comparer règle par règle avant migration. Biome propose des commandes de migration depuis une configuration ESLint existante, documentées sur le site du projet.

Cas où l'adoption est pertinente

• Applications Next.js ou React avec une stack lint standard (hooks, imports, TypeScript).
• Bibliothèques internes où la vitesse de feedback prime sur des règles exotiques.
• Équipes réduites qui veulent un fichier biome.json unique plutôt que .eslintrc + .prettierrc + plugins.

Cas où garder ESLint a du sens

• Règles métier codées dans un plugin maison.
• Politique de formatage qui repose sur des options Prettier non couvertes par Biome.
• Obligation de conformité à un preset d'entreprise encore calé sur ESLint 8 ou 9.

Checklist de test sur un dépôt pilote

• Installation : npm i -D --save-exact @biomejs/biome puis initialisation du fichier de configuration recommandée par la doc.
• Inventaire : lancer biome check ./src sans --write pour lister les écarts sans modifier les fichiers.
• Migration : si vous partez d'ESLint, utiliser la commande de migration officielle et comparer le diff de configuration généré.
• Editor : installer l'extension Biome pour VS Code ou votre IDE afin de formater à la sauvegarde.
• CI : remplacer les jobs eslint et prettier --check par un job biome ci une fois le socle validé en local.
• Rollback : conserver la branche de référence et les anciens scripts pendant un sprint pour revenir en arrière si une règle bloquante apparaît.

Pour aller plus loin sur le blog

Pour compléter votre feuille de route outillage, consultez Vitest : tests unitaires sans friction sur React et Biome : alternative rapide à ESLint et Prettier.

Sources

• Biome, toolchain of the web (site officiel)
• biomejs/biome sur GitHub
• ESLint, outil de lint JavaScript
• Prettier, formateur de code opinionated

Un test pilote de deux semaines sur un dépôt représentatif reste la méthode la plus fiable pour décider si Biome remplace durablement ESLint et Prettier dans votre stack.