リンターを待つのはもうやめましょう：Biomeへの移行でTypeScriptのワークフローを25倍高速化する

Table of Contents

「保存して待つ」サイクルのストレス

誰もが経験したことがあるでしょう。Command+Sを押し、待ちます。フォーマッタがコードを整えるのを待ち、さらに数秒待ってリンターが単純な構文エラーを指摘するのを待ちます。10万行規模のコードベースでは、こうしたわずかな遅延が集中力を削ぎます。CI/CDパイプラインでこれらのツールを実行すると、CPUを数分間占有し、デプロイを遅らせ、クラウドコストを増大させることも珍しくありません。

分断されたツールチェーンの管理は、不要な認知的負荷を生みます。従来、ロジックにはESLintを、見た目にはPrettierを使用してきました。これらは独立して動作するため、頻繁に衝突します。末尾のカンマが必要かどうかでツール同士が争うのを止めるためだけに、何度 eslint-config-prettier をインストールしたか分かりません。

JavaScriptベースのツールの技術的負債

標準的なESLintとPrettierのスタックはNode.js上で構築されています。JavaScriptはアプリケーション構築には優れていますが、巨大な抽象構文木（AST）を処理するような重い作業には苦戦します。チェックを実行するたびに、ESLintがコードをパースし、Prettierが再びパースします。TypeScriptを使用している場合、3回目のパースが発生することもあります。この重複した作業こそが、ファイルを保存するたびにCPUファンが回り出す理由です。

依存関係の肥大化も, 目に見えない問題です。標準的なReactプロジェクトでは、基本的なリンティング、フック、アクセシビリティルールの処理だけで15〜20ものパッケージが必要になることがあります。この node_modules の網を維持するのは骨が折れます。また、リンティングプロセスのコールドスタート時間を延ばし、「即座」のフィードバックを不可能にします。

Biome vs. 従来のスタック

Biome（旧Rome）は、これらのタスクをRustで書かれた単一のツールに統合することで解決します。単一のパーサーを使用することで、より効率的に処理を行います。

主なパフォーマンスの違い

ESLint + Prettier: 通常、シングルスレッドで動作し、ソースコードに対して複数回のパスを必要とします。
Biome: Rustで構築されており、デフォルトで高度に並列化されています。リンティング、フォーマット、インポートの整理を、すべてのCPUコアを使って一回のパスで処理します。

実際のプロジェクトでの結果は驚異的です。私が管理していた約500ファイルのTypeScriptプロジェクトでは、リンティングとフォーマットの合計時間が18秒からわずか0.45秒に短縮されました。このスピードにより、ツールは「コミット前に実行する面倒な作業」から「集中力を維持するための即時フィードバックループ」へと変わります。

移行のメリットとデメリット

メリット

圧倒的なスピード: 現在のセットアップと比較して、20倍から25倍のパフォーマンス向上が期待できます。
クリーンな設定: .eslintrc、.prettierrc、.eslintignore を削除できます。すべてが1つの biome.json ファイルに集約されます。
賢明なデフォルト設定: Biomeは標準的な業界基準にそのまま準拠しているため、設定ルールの議論に時間を費やす必要がありません。
オールインワン: 追加のプラグインなしで、フォーマット、リンティング、インポートのソートを処理します。

デメリット

プラグインエコシステム: Biomeは、ESLintで利用可能な数千ものニッチなプラグインをサポートしていません。非常に特殊なフレームワークルールを使用している場合は、まず互換性を確認してください。
成熟度: 比較的新しいプロジェクトです。本番環境で利用可能ですが、コミュニティのリソースは10年の歴史があるESLintのエコシステムに比べればまだ小規模です。

TypeScriptのための軽量なセットアップ

BiomeはTypeScriptに最適です。TypeScriptとJSXの構文をネイティブにパースするため、@typescript-eslint/parser とそれに付随するオーバーヘッドをついにアンインストールできます。移行の目標は、可能な限り多くの「接着剤のようなコード（glue code）」を取り除くことです。

ステップバイステップ移行ガイド

以下の手順に従って、プロジェクトをクリーンアップし、Biomeを統合しましょう。

ステップ1: Biomeのインストール

Biomeを開発依存関係として追加します。--save-exact フラグを使用することで、チーム全員が同じバージョンを使用し、フォーマットの不一致を避けることができます。

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

ステップ2: 設定の初期化

単一のコマンドで biome.json ファイルを生成します。

npx biome init

これによりベース設定が作成されます。以下は、標準的なPrettierのスタイルに合わせた、実戦向けの構成例です。

{
  "$schema": "https://biomejs.dev/schemas/1.8.3/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 80
  }
}

ステップ3: レガシーパッケージの削除

ここからが醍醐味です。不要なものを削除しましょう。Biomeに完全に移行する場合は、以下のパッケージを安全に削除できます。

npm uninstall eslint prettier eslint-plugin-react eslint-config-prettier @typescript-eslint/eslint-plugin @typescript-eslint/parser

これを実行した後、ルートディレクトリを綺麗に保つために古い設定ファイルを削除してください。

ステップ4: スクリプトの更新

package.json 内の古いリンティングコマンドを置き換えます。check コマンドは、リンティング、フォーマット、インポートのソートを一度に行う、あなたの新しい相棒になります。

"scripts": {
  "check": "biome check --apply ./src",
  "check:ci": "biome check ./src",
  "format": "biome format ./src --write"
}

ステップ5: VS Codeの設定

マーケットプレイスからBiome拡張機能をインストールします。メインツールとして使用するために、.vscode/settings.json を更新します。

{
  "[typescript]": {
    "editor.defaultFormatter": "biomejs.biome"
  },
  "editor.codeActionsOnSave": {
    "source.organizeImports.biome": "explicit",
    "quickfix.biome": "explicit"
  }
}

実際の成果：CIパイプラインへの影響

大規模なエンタープライズ向けダッシュボードをBiomeに移行した際、結果は一目瞭然でした。CIパイプラインの「Lint and Format」ステップは2分45秒からわずか7秒に短縮されました。興味深いことに、その7秒のほとんどはCI環境の初期化に費やされており、実際のコード解析は1秒未満で完了していました。

スピード以外にも、競合する「赤い波線」に悩まされることがなくなりました。Biomeは統合されたエンジンであるため、矛盾したアドバイスを出すことがありません。エラーが表示された場合、それは2つのツール間の設定ミスではなく、本当の問題であることを意味します。

次のステップへ

ESLintとPrettierを手放すのは、その普及度を考えると大きな一歩に感じるかもしれません。しかし、業界がViteやBiomeのような高性能なRust製ツールへと移行しているのには理由があります。スタックを簡素化することで、メンテナンスやバーの読み込みを待つ時間を自分の手に取り戻すことができます。

今日から新しいプロジェクトを始めるなら、Biomeをデフォルトにしましょう。既存のプロジェクトでも、移行は昼休み中に終わるほどシンプルであり、保存するたびにそのパフォーマンスの恩恵を実感できるはずです。