Linter / Formatter は『コードベース全体の品質基盤』
2024年以降、Rust 製の Biome が ESLint+Prettier の代替として注目を集めています。本記事では編集部の視点で、両者の選び方を公開情報をもとに整理します。TypeScript 上級 もご参考に。
Biome の特徴
(1) Rust 製で超高速：ESLint の数十倍(公開情報をもとに)。(2) 1ツールで完結：linter+formatter+import organizer。(3) シンプルな設定：biome.json 1ファイル。(4) ESLint ルール一部互換。(5) 開発体験：エディタ統合がスムーズ。
ESLint の特徴
(1) エコシステム最大：あらゆるルール/プラグイン。(2) Flat Config：v9 から新形式。(3) TypeScript 統合：typescript-eslint で充実。(4) Prettier 併用が長年の標準。(5) カスタムルールを書きやすい。
選択の判断軸
(1) ビルド速度重視：Biome。(2) 豊富なルール必要：ESLint。(3) 新規プロジェクト：Biome 試す価値あり。(4) 既存大規模：ESLint 継続+段階移行。(5) チームの慣れ：学習コストも考慮。
導入の手順
(1) pnpm/npm install --save-dev @biomejs/biome。(2) biome initで設定生成。(3) biome check .で全体チェック。(4) pre-commit hook 設定：lefthook/husky。(5) VS Code 拡張：自動修正設定。CI/CD 実践 もご参考に。
ハイブリッド運用
(1) Biome で format+ESLint でlint。(2) 移行期の選択肢として有効。(3) 段階的に Biome に集約。(4) ルール重複に注意。(5) Monorepo では package 別運用も可。Monorepo 設計 もご参考に。
CI 統合
(1) biome ci .：CI 用のチェック。(2) 差分のみチェック：PR で高速化。(3> error/warning 分離。(4) SARIF 出力：GitHub Code Scanning。(5) ESLint vs Biome の比較：CI 時間で大差。
失敗しがちなパターン
(1) 移行中に両方有効化：ルール衝突。(2) ESLint カスタムルール依存：移行困難。(3) Biome のルール網羅性過信：抜けが残る。(4) format on save 未設定：壊れた状態でコミット。(5) チーム合意なし。対策は、(1)段階移行、(2)代替ルール確認、(3)残りはESLint併用、(4)エディタ設定統一、(5)合意+ロードマップ、です。