Biome 2 : le guide de la chaîne d'outils JavaScript unifiée

Pendant une décennie, chaque projet JavaScript a payé la même taxe : installer ESLint, installer Prettier, installer une douzaine de plugins pour les empêcher de se battre, puis attendre. Deux outils, deux fichiers de configuration, deux passes sur le code, et une part mesurable de chaque exécution d'intégration continue dépensée rien que pour le formatage et le linting.

Biome réduit cette pile à un seul binaire. Écrit en Rust, il formate et analyse JavaScript, TypeScript, JSX, JSON, CSS et GraphQL depuis un unique fichier de configuration, en une seule passe, assez vite pour que vous cessiez d'y penser. Avec la version 2 — la dernière ligne stable est Biome 2.2 — il accomplit ce qui exigeait auparavant le compilateur TypeScript complet : le linting typé, sans aucune dépendance au compilateur.

Ce guide explique ce qu'est Biome 2, pourquoi les équipes migrent et comment l'adopter sans réécriture risquée d'un seul coup.

Pourquoi une chaîne d'outils unique surpasse deux

Le modèle « ESLint plus Prettier » fonctionne, mais il tient avec de la colle. Prettier formate ; ESLint analyse ; le paquet eslint-config-prettier n'existe que pour désactiver les règles ESLint qui entrent en conflit avec Prettier. Vous maintenez .eslintrc, .prettierrc, deux fichiers d'exclusion et une carte mentale de l'outil qui décide quoi.

Biome possède l'ensemble. Un seul biome.json contrôle le formateur, le linter et l'organiseur d'imports. Il n'y a pas de couche de résolution de conflit parce qu'il n'y a pas deux outils pour entrer en conflit. Et comme c'est un binaire natif qui fait le travail, l'écart de vitesse n'est pas subtil — Biome formate et analyse typiquement une grande base de code en une fraction du temps que prend la chaîne équivalente en JavaScript, soit la différence entre un hook de pré-commit que l'on garde et un que l'on désactive en silence.

Le bénéfice est concret : moins de dépendances, une seule configuration à raisonner, et une étape de linting en CI qui se termine avant que vous n'ayez changé d'onglet.

Premiers pas

Installez Biome en dépendance de développement et laissez-le écrire une configuration de départ :

npm install --save-dev --save-exact @biomejs/biome
npx biome init

Cela crée un biome.json à la racine du projet. Voici une version minimale mais prête pour la production :

{
  "$schema": "https://biomejs.dev/schemas/2.2.0/schema.json",
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "useIgnoreFile": true
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "assist": {
    "enabled": true,
    "actions": {
      "source": {
        "organizeImports": "on"
      }
    }
  }
}

Notez le bloc vcs : avec useIgnoreFile à true, Biome respecte votre .gitignore existant, vous évitant de maintenir une liste d'exclusion séparée.

Les trois commandes que vous utilisez vraiment

L'interface de Biome est volontairement réduite. Trois commandes couvrent le travail quotidien :

# Formater les fichiers sur place
npx biome format --write ./src
 
# Analyser et corriger automatiquement ce qui est sûr
npx biome lint --write ./src
 
# Tout faire d'un coup : formater, analyser, organiser les imports
npx biome check --write ./src

biome check est la commande à brancher dans les hooks de pré-commit et la CI. Elle exécute le formateur, le linter et les actions d'assistance (comme l'organisation des imports) en une seule passe sur les fichiers. En CI, retirez le drapeau --write pour qu'elle signale les problèmes et sorte avec un code non nul au lieu de modifier les fichiers.

Ce qui est réellement nouveau dans Biome 2

La version 1 battait déjà l'ancienne pile en vitesse. La version 2 comble l'écart de fonctionnalités qui retenait certaines équipes sur ESLint.

Le linting typé sans compilateur TypeScript. C'est le titre principal. Les règles qui doivent savoir si une expression est une Promise, ou si une valeur est un tableau de promesses, exigeaient traditionnellement qu'ESLint exécute le vérificateur de types TypeScript complet — lent, et dépendant directement du paquet typescript lui-même. Biome 2 embarque son propre moteur d'inférence de types écrit en Rust. Une règle comme noFloatingPromises peut demander « quel est le type de cette expression ? » et obtenir une réponse sans jamais invoquer tsc. Vous obtenez la sûreté des règles typées à vitesse native.

L'analyse multi-fichiers. Biome 2 peut raisonner au-delà des frontières des fichiers, ce qui débloque des règles dépendant des imports et exports plutôt que d'un fichier isolé — le fondement pour détecter de vraies erreurs inter-modules.

Les plugins via GritQL. Vous pouvez désormais écrire des règles de linting personnalisées avec GritQL, une syntaxe de recherche structurelle de code, sans compiler un plugin Rust ni apprendre les rouages internes de Biome. C'était l'échappatoire la plus demandée pour les équipes aux conventions maison.

Les domaines. Les règles peuvent être groupées et activées par domaine — par exemple un domaine react ou test — pour activer un ensemble cohérent de règles conscientes du framework au lieu de fouiller des centaines d'interrupteurs individuels.

Les actions d'assistance. Au-delà du linting, Biome 2 dispose d'une catégorie « assist » pour les actions de source qui ne sont pas des erreurs, comme organiser les imports ou trier les clés d'objet avec useSortedKeys. Elles s'exécutent dans le cadre de biome check.

Migrer depuis ESLint et Prettier

Vous n'avez pas à réécrire votre configuration à la main. Biome lit votre configuration existante et la convertit :

# Récupérer vos préférences de formatage Prettier
npx biome migrate prettier --write
 
# Traduire vos règles ESLint en équivalents Biome
npx biome migrate eslint --write

Ces commandes fusionnent vos options Prettier et vos règles ESLint actuelles dans biome.json, en préservant les décisions déjà prises par votre équipe. Le chemin de migration pratique est incrémental : adoptez d'abord Biome comme formateur (c'est le changement le moins risqué et le plus consensuel), vérifiez que le diff est propre, puis basculez le linting règle par règle. Gardez ESLint installé pour toute règle que Biome ne couvre pas encore, et retirez-le une fois la couverture complète.

Un séquencement réaliste :

Installez Biome et lancez biome migrate prettier.
Formatez tout le dépôt une fois avec biome format --write et validez cela comme un changement isolé, facile à relire.
Lancez biome migrate eslint, puis activez le linter en CI aux côtés d'ESLint (sans le remplacer).
À mesure que les règles de Biome font leurs preuves, supprimez la configuration ESLint redondante jusqu'à pouvoir retirer ESLint entièrement.

Prise en charge des monorepos

Biome 2 a ajouté une gestion de premier ordre des monorepos. Vous conservez un biome.json racine unique avec les valeurs par défaut partagées, et les paquets imbriqués peuvent avoir leur propre configuration qui l'étend ou la surcharge. Les configurations imbriquées doivent déclarer "root": false afin que Biome sache qu'elles font partie d'un projet plus vaste et non de racines indépendantes — la commande biome migrate signale tout fichier imbriqué qui l'oublie. Le résultat : des standards partagés à l'échelle de l'espace de travail, avec des échappatoires par paquet là où elles se justifient.

Intégration éditeur et CI

Biome dispose d'une extension officielle pour VS Code (et d'intégrations pour d'autres éditeurs via le protocole Language Server). Définissez-la comme formateur par défaut et activez le formatage à l'enregistrement : l'expérience éditeur égale celle de Prettier — formatage instantané, plus des diagnostics de linting en ligne issus du même moteur qui tourne en CI. Cette propriété de source unique de vérité compte : ce que votre éditeur signale est exactement ce que la chaîne signale, sans dérive de version entre un plugin Prettier et un plugin ESLint distinct.

Pour la CI, l'étape tient en une ligne :

npx biome ci ./src

biome ci est un mode dédié qui vérifie le formatage et le linting sans écrire de changements, ajusté pour la sortie d'intégration continue.

Où Biome s'inscrit

Biome est le choix le plus solide lorsque vous voulez une chaîne d'outils unique, rapide et affirmée, et que votre pile relève du web courant qu'il couvre : JS, TS, JSX, JSON, CSS, GraphQL. Ce n'est pas encore un remplacement total de chaque plugin ESLint de niche, et les composants monofichiers Vue ou Svelte continuent de mûrir — vérifiez donc la couverture pour votre framework précis avant de basculer entièrement. Pour la grande majorité des projets React, Next.js et Node, en revanche, l'échange est clair : vous troquez deux outils lents et une couche de résolution de conflit contre un binaire qui fait le travail en une fraction du temps.

Si vous comptiez ranger votre outillage, le chemin incrémental rend l'essai quasi gratuit. Commencez par le formateur sur une branche, regardez le diff, et laissez la vitesse plaider.