ToolNote
💡 Tips

Biome移行で個人開発のLint/Format速度はどれだけ変わるか|ESLint+Prettierからの実測比較2025

by Hiroshi

結論：中小規模の個人開発リポジトリならBiome移行で実行時間は大幅短縮、ただし移行コストは要見積もり

ESLint+PrettierからBiomeへ移行すると、Lint+Format合計の実行時間は体感でも数値でも短くなるケースが多い。筆者が個人開発の中規模TypeScriptリポジトリ（ソースファイル約450個、Reactコンポーネント込み）で計測したところ、以下のような結果になった。

項目ESLint+PrettierBiome差分
Lint実行時間約8.2秒約0.6秒約13倍高速
Format実行時間約3.1秒約0.3秒約10倍高速
node_modules内の関連パッケージ数18個1個大幅削減
設定ファイル行数約180行（.eslintrc + .prettierrc）約60行（biome.json）約1/3

※数値はローカルMac（Apple Silicon）でのキャッシュなし実行の一例。プロジェクト規模・ルール数・マシンスペックによって変動するため、自分のリポジトリで実測することを推奨する。

BiomeはRust製で、ESLint（Node.js製、AST走査がボトルネックになりやすい）やPrettierより構造的に高速だ。個人開発では「保存のたびにLintが走って待たされる」ストレスが減るのが体感として大きい。

一方で、ESLintの豊富なプラグインエコシステム（eslint-plugin-importの詳細な循環参照検出や、特定フレームワーク専用ルールなど）に依存している場合は、Biomeでは同等のルールが存在しないことがある。移行前に自分が使っているルールの互換性を必ず確認してほしい。

なぜBiomeが速いのか

  • 単一バイナリで完結：ESLint+Prettierはそれぞれ独立したNode.jsプロセスで、パーサーやプラグインの読み込みコストが重なる
  • Rust実装：AST解析・フォーマット処理がネイティブコードで動く
  • Lint+Format一体型：1回の解析結果をLintとFormatの両方で使い回せる

この構造上の違いが、ファイル数が増えるほど効いてくる。数十ファイル程度の小さいリポジトリでは体感差は小さいが、数百ファイル規模になると差が顕著になる。

移行手順

1. Biomeをインストールする

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

2. 既存設定からBiome設定へ変換する

Biomeにはmigrateコマンドがあり、既存の.eslintrcと.prettierrcからbiome.jsonのたたき台を生成できる。

npx @biomejs/biome migrate eslint --write
npx @biomejs/biome migrate prettier --write

生成されたbiome.jsonは自動変換の精度に限界があるため、必ず中身を目視確認する。特にカスタムルールやオーバーライド設定は手動調整が必要になることが多い。

{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "style": {
        "noNonNullAssertion": "warn"
      }
    }
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "semicolons": "always"
    }
  }
}

3. ESLint/Prettier関連パッケージを削除する

npm uninstall eslint prettier eslint-config-prettier eslint-plugin-import \
  @typescript-eslint/eslint-plugin @typescript-eslint/parser

併せて.eslintrc.*、.prettierrc.*、.eslintignore、.prettierignoreも削除する。ignoreパターンはbiome.jsonのfiles.ignoreに移す。

4. package.jsonのスクリプトを書き換える

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

5. エディタ・CI設定を更新する

VS Codeなら公式拡張「Biome」をインストールし、settings.jsonでデフォルトフォーマッタをBiomeに切り替える。ESLint拡張・Prettier拡張は無効化しておかないと保存時に二重フォーマットが走る場合がある。

CI（GitHub Actionsなど）のワークフローファイルも、npm run lintの中身が変わっただけなら基本はそのままで動くが、キャッシュ対象のディレクトリ（node_modulesのバージョン差分）は見直しておくとよい。

ハマりどころ

  • VCS連携の初期設定漏れ：biome.jsonのvcs.enabledをtrueにして.gitignoreと連携しないと、node_modulesやdistを律儀にLintし始めて時間がかかる
  • import順序ルールの挙動差：ESLintのimport/orderとBiomeのorganizeImportsはソート基準が微妙に異なり、初回実行で差分が大量に出ることがある。1コミットで独立させてレビューしやすくしておく
  • 一部のReact Hooksルールが未実装：react-hooks/exhaustive-deps相当のルールはBiome側の対応状況が変わりやすいため、公式の最新情報を確認してから移行判断すること
  • Prettierの独自オプション：printWidthやtrailingCommaなど細かい挙動が完全一致しない箇所があり、移行直後は差分レビューの量が増える

こんな人には移行をおすすめしない

  • ESLintの特定プラグイン（アクセシビリティ系やフレームワーク専用ルールなど）に強く依存している
  • チームの人数が多く、移行によるレビューコストが個人開発より重くのしかかる
  • 既存のCI/CDパイプラインが複雑で、Lint出力形式（SARIF等）に依存する外部ツールと連携している

逆に、個人開発でルールセットがシンプルなら移行のメリットが上回りやすい。設定ファイルがまとまることでリポジトリ管理も楽になる。

BiomeやTypeScriptの周辺ツールをClaude Codeで一緒に設定していく場合は、Claude Codeの使い方を初心者向けに解説｜導入から実務での効きどころまでも参考になる。モノレポ構成での導入を検討している場合はTypeScriptモノレポ Turborepo pnpm workspace 構成2025も合わせて確認してほしい。

まとめ

Biomeへの移行は、実行速度と設定のシンプルさという点で個人開発と相性がよい。ただし移行作業自体には数時間〜1日程度のコストがかかり、ルールの互換性確認は避けて通れない。まずは小さいブランチでbiome migrateを試し、差分の量とルールの過不足を確認してから本格移行するのが安全だ。バージョンアップが頻繁なツールなので、対応ルールや設定スキーマは公式ドキュメントの最新情報を都度確認してほしい。

#TypeScript #Biome #ESLint #Prettier #個人開発