TL;DR

• Biome est un linter + formatter ecrit en Rust qui remplace ESLint et Prettier dans un seul outil.
• La performance est reelle : 10-15x plus rapide sur un monorepo de taille moyenne.
• La migration depuis ESLint/Prettier est simple : biome migrate fait 90% du travail.
• Ce qui manque encore : certains plugins ESLint populaires (import sorting avance, rules specifiques React).
• Pour un nouveau projet, Biome par defaut. Pour un projet existant, migre quand tu veux -- c'est pas urgent.

Le probleme avec ESLint + Prettier

Soyons honnetes : configurer ESLint et Prettier sur un projet TypeScript moderne, c'est un calvaire.

Tu commences avec ESLint. Tu ajoutes @typescript-eslint/parser. Puis @typescript-eslint/eslint-plugin. Puis eslint-config-prettier pour eviter les conflits avec Prettier. Puis eslint-plugin-import pour les imports. Puis eslint-plugin-react si tu fais du React. Puis eslint-plugin-react-hooks. Puis un preset partage pour que tout soit coherent.

Tu te retrouves avec un .eslintrc.js de 80 lignes, un .prettierrc separe, un package.json avec 12 devDependencies juste pour le linting, et un temps d'execution de 8 secondes sur lint-staged qui rend chaque commit penible.

Et quand ESLint 9 est sorti avec le flat config, ca a empire. La migration de .eslintrc vers eslint.config.js a casse la moitie des plugins existants. Pendant des mois, certains plugins ne supportaient que l'ancien format, d'autres que le nouveau. Le chaos.

C'est dans ce contexte que Biome a gagne en traction en 2025.

Biome : un outil pour les gouverner tous

L'histoire rapide

Biome est le successeur de Rome, le projet ambitieux de Sebastian McKenzie (createur de Babel). Rome voulait etre un "unified toolchain" pour JavaScript : parser, linter, formatter, bundler, test runner -- tout en un. Le projet etait trop ambitieux et a implose en 2023.

Biome a recupere le code, recentre le scope sur le linting et le formatting, et livre. Ecrit en Rust, single binary, zero config par defaut. Pas de plugins, pas de presets, pas de 47 dependances transitives. Un seul outil qui fait deux choses bien.

Ce que ca donne en pratique

# Installation
npm install --save-dev @biomejs/biome

# Initialisation
npx biome init

# Lint + Format en une commande
npx biome check .

# Auto-fix
npx biome check --write .

# Format uniquement
npx biome format --write .

Le fichier de configuration biome.json est minimal :

{
  "$schema": "https://biomejs.dev/schemas/1.9.0/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "trailingCommas": "all",
      "semicolons": "always"
    }
  }
}

20 lignes. Tout est la : linting, formatting, import sorting, config TypeScript. Compare ca aux 80 lignes de .eslintrc.js + .prettierrc + tsconfig.json overrides.

La migration : comment j'ai fait

Mon setup avant

Un monorepo Next.js avec trois apps et cinq packages partages. Le setup ESLint/Prettier :

• eslint + @typescript-eslint/parser + @typescript-eslint/eslint-plugin
• eslint-config-next (pour les apps Next.js)
• eslint-plugin-import + eslint-import-resolver-typescript
• eslint-plugin-react + eslint-plugin-react-hooks
• prettier + eslint-config-prettier
• Un .eslintrc.js partage au root, surcharge par app
• Un .prettierrc au root

12 devDependencies, 3 fichiers de config, et npm run lint qui prenait 8.2 secondes.

Etape 1 : Generer la config Biome depuis ESLint

npx biome migrate eslint --write

Cette commande lit ton .eslintrc et genere un biome.json equivalent. Elle mappe les rules ESLint vers les rules Biome quand un equivalent existe, et liste celles qui n'ont pas d'equivalent.

Dans mon cas, 85% des rules avaient un equivalent direct. Les 15% restantes etaient des rules specifiques a eslint-plugin-import (import order) et quelques rules React niche.

Etape 2 : Generer la config formatter depuis Prettier

npx biome migrate prettier --write

Meme principe : Biome lit ton .prettierrc et configure son formatter en consequence. Les options principales (indent, quotes, semicolons, trailing commas, line width) sont toutes supportees.

Etape 3 : Lancer Biome sur le codebase

npx biome check --write .

Premier run : 847 fichiers analyses en 0.6 secondes. 23 erreurs de lint, 156 fichiers reformates.

Les 23 erreurs etaient toutes des vrais problemes que ESLint ne detectait pas (variables inutilisees dans des destructurings, imports de types qui auraient du etre import type). Biome est plus strict que ESLint par defaut sur certaines rules, et c'est une bonne chose.

Etape 4 : Nettoyer l'ancien setup

# Supprimer les configs
rm .eslintrc.js .eslintignore .prettierrc .prettierignore

# Supprimer les dependances
npm uninstall eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin \
  eslint-config-next eslint-config-prettier eslint-plugin-import \
  eslint-import-resolver-typescript eslint-plugin-react \
  eslint-plugin-react-hooks prettier

12 dependances en moins. Le node_modules a perdu 45 Mo.

Etape 5 : Mettre a jour les scripts

{
  "scripts": {
    "lint": "biome check .",
    "lint:fix": "biome check --write .",
    "format": "biome format --write .",
    "format:check": "biome format ."
  }
}

Et le lint-staged :

{
  "lint-staged": {
    "*.{js,ts,tsx,jsx,json,css}": ["biome check --write --no-errors-on-unmatched"]
  }
}

Les benchmarks : avant et apres

Les gains sont massifs. Et ce n'est pas un benchmark synthetique -- c'est mon monorepo reel, avec de vrais fichiers, mesure avec time. Le passage de 2.4s a 0.2s sur lint-staged est celui qui se ressent le plus au quotidien. Chaque commit est instantane.

Ce qui manque encore

Biome n'est pas parfait. Voici ce qui m'a manque apres la migration.

Pas de plugins

ESLint a un ecosysteme de plugins massif. Biome n'a pas de systeme de plugins (c'est un choix delibere). Ca veut dire :

• Pas de eslint-plugin-import complet : Biome trie les imports, mais les rules avancees (no-cycle, no-self-import) n'existent pas
• Pas de rules custom : si tu avais des rules ESLint specifiques a ton projet, tu ne peux pas les porter
• Pas de eslint-plugin-jsx-a11y : les verifications d'accessibilite ne sont pas encore la (c'est sur la roadmap)

CSS et HTML partiels

Biome supporte le linting et formatting de JavaScript, TypeScript, JSX, TSX, JSON et CSS. Mais le support CSS est encore jeune. Si tu as des besoins avances en linting CSS (stylelint-like), garde un outil dedie.

Integration IDE

Le plugin VS Code fonctionne bien. WebStorm aussi. Mais certains editeurs moins populaires n'ont pas de support officiel. Si tu utilises Neovim, le LSP Biome fonctionne, mais la configuration demande du travail.

ESLint config Next.js

Si tu utilises eslint-config-next, tu perds quelques rules specifiques a Next.js (comme les warnings sur <Image> sans width/height). Ce n'est pas critique, mais c'est a savoir.

Quand migrer, quand rester

Migre maintenant si :

• Tu commences un nouveau projet. Biome par defaut, zero question.
• Tu as un monorepo et le lint time est un bottleneck. Les gains de performance sont immediats.
• Tu es fatigue de maintenir la config ESLint/Prettier. Biome simplifie drastiquement.
• Tu ne depends pas de plugins ESLint specifiques.

Reste sur ESLint si :

• Tu depends de eslint-plugin-import pour les rules avancees (no-cycle, boundaries)
• Tu as des rules ESLint custom qui sont critiques pour ton equipe
• Tu utilises eslint-plugin-jsx-a11y et l'accessibilite est une priorite (attends que Biome le supporte)
• Ton setup ESLint fonctionne et tu n'as pas de probleme de performance

Mon conseil

Pour un nouveau projet en 2025-2026, Biome est le choix par defaut. La DX est meilleure, la performance est incomparable, et la configuration est triviale. Les quelques rules manquantes ne justifient pas la complexite d'ESLint + Prettier + 12 plugins.

Pour un projet existant, il n'y a pas d'urgence. ESLint ne va pas disparaitre demain (la version 9 avec flat config est solide). Migre quand tu as un sprint calme, un vendredi apres-midi, ou quand la frustration avec ton setup actuel depasse le cout de la migration.

La migration elle-meme est simple. biome migrate fait le gros du travail. Une heure pour un petit projet, un apres-midi pour un monorepo. Et une fois fait, tu ne regardes plus en arriere.

Le futur de Biome

La roadmap 2026 est ambitieuse : support GraphQL, CSS lint complet, un systeme de plugins (enfin), et des analyses cross-fichiers (comme detecter du code mort a l'echelle du projet). Si Biome tient ses promesses, ESLint va avoir du mal a justifier sa complexite face a un outil qui fait autant, 10x plus vite, en une seule dependance.

La lecon plus large : les outils JavaScript ecrits en Rust ne sont pas un effet de mode. SWC a remplace Babel dans Next.js. esbuild domine le bundling. Biome remplace ESLint + Prettier. Le pattern est clair : les outils de dev migrent vers des langages systemes pour la performance, et le JavaScript se concentre sur la logique applicative.

C'est un bon deal pour tout le monde.

Ressources

• Biome Documentation -- documentation officielle
• Biome Migration Guide -- guide de migration ESLint/Prettier
• Biome Rules Reference -- toutes les rules disponibles
• ESLint Flat Config -- le nouveau format ESLint pour comparaison
• Biome GitHub -- code source et issues