Biome：ESLintとPrettierの「設定の迷宮」に別れを告げ、プロジェクトを25倍高速化する – ITFROMZERO

Table of Contents

ESLintとPrettierの「設定競合」という悩み

ReactやNext.jsのプロジェクトを立ち上げたことがある人なら、大量の補助パッケージをインストールする光景に見覚えがあるはずです。eslint、prettier、さらにeslint-config-prettierやeslint-plugin-prettierなど。コードを綺麗に保ち、正しくフォーマットするだけで、設定に1時間も費やしてしまうことがあります。

問題はセットアップ時だけではありません。私が以前参加した10万行を超える大規模プロジェクトでは、npm run lintの完了に約2分かかっていました。時にはPrettierが修正した箇所をESLintがエラーとして報告し直すといった、いたちごっこが起きることもあります。ツールが本来の目的であるはずの開発効率化を妨げ、ストレスの原因になってしまうのです。

なぜESLintとPrettierの組み合わせは重くなってしまうのか？

LintingとFormattingのために2つの別々のツールを維持することには、いくつかの固有の弱点があります。

鈍足なパフォーマンス: どちらもNode.js上で動作します。プロジェクトが拡大するにつれ、抽象構文木（AST）の解析を繰り返すことでCPUに過度な負荷がかかります。
設定の重複: 両者の衝突を防ぐために、中間的なプラグインを追加で導入する必要があります。
依存関係の増大: package.jsonを見ると、コードフォーマットのためだけのライブラリがnode_modulesの容量を15〜20MBも占有していることがあります。

現在の主な解決策

開発コミュニティでは、主に3つの解決策が語られています。

現状維持: 既存のツールを使い続け、キャッシュを利用して最適化する。安全ですが、速度の根本的な解決にはなりません。
Rust製リンターの使用: 爆速なoxlintなどが代表的です。ただし、現在はリンティングに特化しており、フォーマット機能が不足しています。
Biome（旧Rome）への移行: Rustで書かれたオールインワンツールセットです。ESLintとPrettierの両方を完全に置き換えることができます。

なぜ今、Biomeが「最適解」なのか？

中規模のアウトソーシングプロジェクトでの検証結果によると、BiomeはPrettierよりも約25倍高速です. 数十秒待つ代わりに、Biomeは数千ファイルをわずか数ミリ秒で処理します。リンティング、フォーマット、そしてインポート文の自動ソートが、単一の軽量なバイナリに統合されています。

以下は、プロジェクトを整理してBiomeに移行するために私が行った手順です。

1. 最小限のインストール

5〜6個のパッケージをインストールする代わりに、今後は1つのコマンドだけで済みます。

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

注意： バージョンを固定するために--save-exactを使用してください。これにより、チームメンバー全員が常に同じフォーマットを維持できるようになります。

2. 一瞬で設定ファイルを生成

以下のコマンドを実行して、biome.jsonファイルを作成します。

npx biome init

Biomeの設定は非常に直感的で読みやすいです。以下は、実際のプロジェクトで私がよく適用する設定例です：

{
  "$schema": "https://biomejs.dev/schemas/1.8.3/schema.json",
  "organizeImports": { "enabled": true },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "style": { "useNamingConvention": "warn" }
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "quoteStyle": "single"
  }
}

3. ESLint/Prettierからの自動移行

何百もの既存ルールを書き直すのが面倒ですか？Biomeは非常にスマートな自動変換コマンドを提供しています：

npx biome migrate prettier --write
npx biome migrate eslint --write

ツールは自動的に.eslintrcや.prettierrcファイルを読み取り、同等の設定にマッピングします。このプロセスにより、手動で確認する時間を少なくとも30分は節約できました。

4. 実行速度を体感する

エラーチェックとコード全体の再フォーマットを行うには、以下のコマンドを使用します：

# エラーチェック、自動修正、フォーマットを同時に実行
npx biome check --write .

チーム全体のプロセスを統一するために、これらのコマンドをpackage.jsonのscriptsに追加しておくのが一般的です：

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

GitHub Actionsでの「ガードレール」設定

質の低いコードがメインブランチに混入するのを防ぐため、CIへのBiomeの統合は欠かせません。Biomeは非常に高速に動作するため、パイプラインの待ち時間をほとんど増加させません。

name: CI
on: [push, pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - name: Run Biome
        run: npx @biomejs/biome ci .

biome ci .コマンドは厳格なチェックを行います。コードがフォーマットされていない場合やリンターのエラーがある場合、即座に失敗（Fail）を報告します。

実体験に基づく注意点

Biomeは非常に強力ですが、移行を決定する前にいくつか留意すべき点があります。

エコシステム: BiomeはまだESLintほど膨大なプラグインを持っていません。プロジェクトで非常に特殊なルールを使用している場合は、事前にBiomeのドキュメントを確認してください。
VS Codeの設定: Biome拡張機能をインストールし、それを「Default Formatter」に設定してください。Prettierと並行して動作させると、保存時にフォーマットが競合して乱れる原因になります。
導入戦略: レガシープロジェクトの場合、一気に移行するのではなく、まずはいくつかの小さなフォルダで試して互換性を評価してください。

結論として、速度とシンプルさを重視するならBiomeは有力な選択肢です。ファイルを保存した瞬間にラグなく反映されるスムーズなコーディング体験は、ESLintではなかなか味わえないものです。