ESLint + Prettierの時代は終わったのか？ Biomeがもたらす「開発体験の再定義」と技術的判断基準
エンジニアの皆さん、こんにちは。日々のコードベースで `npm run lint` や `prettier –write` の実行完了を待つ、あの数秒間の「無」の時間に、生産性の損失を感じたことはありませんか？
大規模なモノレポを扱うテックリードとして断言しますが、「ツールを待つ」ことはエンジニアリングにおける最大の負債の一つです。
現在、JavaScript/TypeScriptエコシステムは大きな転換点を迎えています。Rustで書かれた次世代ツールチェーン「Biome」が、長年君臨してきたESLint + Prettierの牙城を崩そうとしています。本稿では、単なる速度比較を超え、アーキテクチャの観点から「移行すべきか否か」を冷徹に分析します。
—
1. なぜ「Biome」は速いのか？：技術的パラダイムの転換
ESLintとPrettierの構成には、根本的な「オーバーヘッド」が存在します。
- ESLint: JavaScriptで書かれており、プラグインの読み込みごとにAST（抽象構文木）を生成し直すコストがある。
- Prettier: ルールの競合を防ぐために `eslint-config-prettier` を噛ませる必要があり、設定の複雑さがCI/CDのボトルネックになる。
対してBiomeは、単一のRustバイナリで「Lint」と「Format」を統合しています。特筆すべきは、「一度のパースでLintとFormatの両方を行う」という設計思想です。これにより、I/O負荷とAST生成コストを極限まで削減しています。
Biomeを導入すべき「決定的な瞬間」
- Prettierの実行がリポジトリ全体のLint時間に占める割合が無視できなくなった時
- チームメンバーが「ESLintの設定競合」によるエラーで1日10分以上浪費している時
—
2. 現場で「震えるほど役立つ」Biome移行戦略
Biomeへの移行は、単なるツールの入れ替えではありません。「設定の断捨離」です。
ベストプラクティス：`biome.json` の構成例
複雑怪奇な `.eslintrc.js` から解放され、Biomeでは宣言的に設定を記述します。
{
“$schema”: “https://biomejs.dev/schemas/1.6.0/schema.json”,
“organizeImports”: {
“enabled”: true // インポートのソートを標準化。Gitの差分爆発を防ぐ
},
“linter”: {
“enabled”: true,
“rules”: {
“recommended”: true, // 推奨ルールをベースに
“style”: {
“useTemplate”: “error” // 文字列結合よりテンプレートリテラルを強制
}
}
},
“formatter”: {
“enabled”: true,
“formatWithErrors”: true, // 構文エラーがあっても整形を試みる（開発体験の向上）
“indentStyle”: “space”,
“indentWidth”: 2
},
“javascript”: {
“formatter”: {
“quoteStyle”: “single” // Prettierの慣習を継承
}
}
}
—
3. 開発スピードを劇的に高めるプロのテクニック
ツール導入後にすべきことは、開発者の「指の動き」をツールに同期させることです。
① VS Codeでの「思考停止」設定
`.vscode/settings.json` に以下を記述し、Biomeをデフォルトフォーマッタに設定します。これにより、保存するたびに「LintとFormat」が瞬時に終わります。
{
“editor.defaultFormatter”: “biomejs.biome”,
“editor.formatOnSave”: true,
“editor.codeActionsOnSave”: {
“quickfix.biome”: “explicit” // 保存時にLintエラーを自動修復
}
}
② チーム開発で役立つ「Husky」との連携
コミット前に強制的にBiomeを走らせることで、コード品質の「最低ライン」を担保します。
.husky/pre-commit に記述
npx @biomejs/biome check –apply –no-errors-on-unmatched –files-ignore-unknown=true .
※ `files-ignore-unknown` を入れるのがコツです。これにより、Biomeが認識できないファイル形式（Markdownなど）でCIが止まる事故を防げます。
—
4. 結論：ESLint + Prettierは捨てるべきか？
私のテックリードとしての評価は以下の通りです。
- 新規プロジェクト: 迷わずBiomeを採用してください。 ESLint + Prettierの複雑な設定を維持するメリットは、現在ほとんどありません。
- 大規模レガシープロジェクト: 「共存」を推奨します。 BiomeはESLintの設定を完全には置き換えられないケース（複雑なカスタムプラグインや特定のフレームワーク固有のルール）があります。まずは `format` 機能だけをBiomeに任せ、Lintは段階的に移行するのが最もリスクが低く、かつ即効性のある投資です。
最後に
ツール選定の基準は「どれが新しいか」ではなく「チームの認知負荷をどれだけ下げられるか」です。
Biomeは単なる高速化ツールではありません。設定ファイルという名の「負債」を消し去り、エンジニアがコードを書くという本来のクリエイティブな活動に集中するための、極めて洗練されたアーキテクチャです。
ぜひ、次回のスプリントでBiomeを試験導入し、あの「爆速」の実行速度を体感してください。開発者のストレスが減り、チームのデプロイ頻度が上がることを保証します。