Biomeは、JavaScriptやTypeScriptなどを対象とするFormatter(コード整形)とLinter(問題の検出)をまとめたツールチェーンです。Biome 2.0では、コードに対する安全な操作を行うAssistや、型情報を利用するLintルールの基盤も追加されました。
まず押さえたい結論
記事情報: 2025年6月25日初出。本文の仕様は2026年7月25日にBiome公式資料で再確認しています。
Biomeを導入すると、整形と静的解析を同じ設定ファイル、同じCLIで扱えます。ただし、「ESLintとPrettierの全機能を、そのまま完全に置き換えられる」という意味ではありません。使用中のESLintプラグイン、Prettierの対応言語、エディタ連携を調べてから判断する必要があります。
Biome 2.0の役割は大きく3つです。
- Formatter: インデントや改行などを一定の形式にそろえる
- Linter: バグや保守性低下につながるコードを検出する
- Assist: importの整理など、コードへ決まった変更を適用する
TypeScriptの型情報を使うLintルールも導入されました。ただし2.0時点では対象が限定され、公式リリースノートも「初期段階」と説明しています。型チェックそのものは引き続きTypeScriptコンパイラなどで行います。
最小構成で試す
公式ガイドは、意図しない更新を避けるためにBiomeのバージョンを固定してインストールする例を示しています。
npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome init
initを実行すると、プロジェクト直下にbiome.jsonが作られます。まずは生成された設定を基準にし、必要な項目だけ変更すると設定理由を追いやすくなります。
{
"$schema": "https://biomejs.dev/schemas/2.0.0/schema.json",
"formatter": {
"enabled": true,
"indentStyle": "space"
},
"linter": {
"enabled": true,
"rules": {
"recommended": true
}
}
}
設定スキーマのURLは、実際に利用するBiomeのバージョンに合わせてください。公式のinitコマンドに生成させれば、手入力による版のずれを避けやすくなります。
主なコマンドは次のとおりです。
# 整形結果を確認する
npx @biomejs/biome format .
# Lintを実行する
npx @biomejs/biome lint .
# 整形とLintをまとめて確認する
npx @biomejs/biome check .
# 適用可能な修正を書き込む
npx @biomejs/biome check --write .
最初からリポジトリ全体を書き換えず、対象ディレクトリを絞って差分を確認するのが安全です。--writeはファイルを変更するため、実行前に作業ツリーを確認してください。
Biome 2.0で変わった点
Assistが独立した機能になった
以前のImport OrganizerはAssistへ移されました。Assistはエラー検出ではなく、コードを一定の状態へ変換する機能です。たとえばimportの整理や、設定ファイル内のキーの並べ替えに使えます。
Lintと役割を分けて考えると理解しやすくなります。Lintは「このコードに問題がある」と報告し、Assistは「決められた並びへ直す」といった操作を担当します。チームで有効化する場合は、どの操作を自動適用するかをレビュー方針に含めます。
型情報を利用するLintルール
Biome 2.0では、TypeScriptコンパイラを別プロセスで動かさず、プロジェクト内の型情報を推論して利用する仕組みが入りました。例として、処理されていないPromiseを検出するnoFloatingPromisesなどが案内されています。
ただし、公式リリース時点では対応ルールも型推論の範囲も限定的です。tsc --noEmitを削除する根拠にはなりません。BiomeのLint、TypeScriptの型チェック、テストは別々の役割としてCIに残します。
HTML対応は状態を確認する
Biome 2.0のHTML Formatterは実験的で、既定では無効でした。また、リリース時点の対象はHTMLファイルで、VueやSvelteに埋め込まれたHTMLを同じように扱えるとは限りません。現在の導入時には、使用バージョンの言語サポート表と設定リファレンスを確認してください。
ESLint・Prettierから移行する
Biomeには既存設定を変換するコマンドがあります。
npx @biomejs/biome migrate eslint --write
npx @biomejs/biome migrate prettier --write
ただし移行はbest effort、つまり変換できる範囲での支援です。ESLintのプラグイン固有ルールや、PrettierとBiomeで判断が異なる整形は、そのまま再現されない場合があります。
安全な移行手順は次の順番です。
- 現在のESLint・Prettier設定とCIコマンドを記録する
- 移行コマンドを実行し、生成された
biome.jsonを読む - 小さなディレクトリで
biome checkを試す - 自動修正の差分をレビューする
- 未対応ルールがあればESLintとの併用期間を設ける
- エディタとCIの結果が一致してから旧設定を外す
移行PRでは、大量の整形差分と機能変更を混ぜないほうがレビューしやすくなります。最初に機械的な整形だけを適用し、Lintルールの変更は別の差分に分ける方法が有効です。
CIとエディタで使う
CI向けにはbiome ciが用意されています。ローカルで自動修正し、CIでは差分を書き込まず失敗を検出する構成にすると役割が明確です。
{
"scripts": {
"format": "biome format --write .",
"check": "biome check .",
"ci": "biome ci .",
"typecheck": "tsc --noEmit"
}
}
name: quality
on:
pull_request:
jobs:
biome:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run ci
- run: npm run typecheck
BiomeはVS Codeなど向けの公式拡張を提供しています。保存時整形を有効にする場合は、BiomeとPrettierの両方が同じファイルを整形しないよう、言語ごとの既定Formatterを確認します。CLIのバージョンはプロジェクト依存関係に固定し、エディタ拡張からもプロジェクトのBiomeを使うと差異を減らせます。
導入判断のチェックポイント
Biomeが向いているのは、JavaScript・TypeScript中心で、整形と一般的なLintルールを少ない構成で統一したいプロジェクトです。一方、特定のESLintプラグインへ強く依存する場合や、Biomeが未対応の言語をPrettierで整形している場合は、部分導入や併用が現実的です。
判断時は速度の宣伝値ではなく、次を手元のリポジトリで確認してください。
- 必須のLintルールがBiomeにあるか
- 対象拡張子がFormatterで正式対応されているか
- 自動修正後もテストと型チェックが通るか
- IDE、ローカルCLI、CIで同じ結果になるか
- 抑制コメントや除外設定をチームで説明できるか
Biomeは設定をまとめる選択肢ですが、品質保証を1コマンドだけに置き換える道具ではありません。Formatter、Linter、型チェック、テストの境界を保ったまま導入すると、安全に利点を得られます。