Biome を formatter と linter の統合点から評価する

JS と TS の開発ツールを一つにする

Biome は README で JavaScript と TypeScript のための formatter、linter などをまとめたツールチェーンとして説明されています。複数の開発ツールを個別に実行する構成から、単一の CLI と設定へ整理したい場合に検討対象になります。

統合は設定が少なくなることと同義ではありません。既存プロジェクトが使う parser、ルール、ignore、生成コードの扱いを洗い出し、Biome が同じ入力にどんな変更と診断を返すかを比較します。

設定ファイルから適用範囲を固定する

Biome の挙動はプロジェクト内の設定とコマンドライン引数の組み合わせで決まります。README の設定例を起点に、対象ディレクトリ、除外パターン、formatter のスタイル、linter の有効ルールを明示します。

設定を置いた場所によって、モノレポの各 package にどこまで届くかが変わります。ルートとサブディレクトリに意図しない設定がないかを確認し、同じファイルを二度実行して差分が増えないことも試します。

CLI の終了コードを CI に接続する

ローカルで表示がきれいでも、CI が何を失敗とみなすかは別の契約です。format check と write、lint の各モードを分け、変更がある場合と診断がある場合の終了コードを記録します。

移行時は既存 CI のコマンドを一度に置き換えず、同じ commit で旧ツールと Biome を実行します。出力されたファイル差分、警告の数、終了コードを比較すれば、ルールの変更と単なる整形差分を分離できます。

既存 formatter から移行する際の差分

formatter の置換では、インデントだけでなく引用符、末尾カンマ、改行、JSX、JSON の扱いが変わることがあります。大きな一括差分を機能変更と混ぜるとレビューが難しくなるため、設定導入の commit とロジック変更を分けます。

Biome が README で明示していない互換性は、プロジェクトの実ファイルで確認します。特殊な syntax、生成ファイル、vendor ディレクトリを選び、期待する除外が働くことを CLI の対象ファイル表示と git diff で検証します。

ルールの速度と診断を測る

Biome は高速な開発ツールとして紹介されていますが、素材の README は自分のコードベースにおける実行時間や CI 削減を保証しません。測定ではファイル数、キャッシュの有無、cold run と再実行を分けて記録します。

診断の採用は数ではなく、修正可能性と誤検知の確認で決めます。代表的な違反を含む fixture を作り、メッセージ、位置、fix の結果、fix 後の再実行を確認します。

採用するチームとライセンス確認

Biome の採用は、JavaScript と TypeScript の品質ルールを repository 単位で管理し、開発者と CI の実行方法を揃えたいチームに合います。別言語の検査や高度な既存プラグインが中心なら、置換範囲を限定します。

ライセンス、対応版、リリース履歴はリポジトリ、README、Releases で照合します。最初の合否条件を、設定の再現、formatter の安定性、lint の終了コード、CI の所要時間、既存ルールとの差分に置けば、印象ではなく実ファイルで判断できます。

差分を CI の合否条件へ変換する

Biome の導入 commit では、既存 formatter が作る差分と Biome が作る差分を別々に保存します。次の commit で formatter check を実行し、変更がない場合は成功、整形が必要な場合は失敗になることを CI の実ログで確認します。

lint は診断のある fixture とない fixture を用意し、終了コード、行番号、fix の前後を比較します。設定ファイルの場所と対象 glob を変えたケースも試し、モノレポの一つの package だけを修正したときに別 package のファイルが書き換わらないことを確認します。

biome の試験結果は、成功したかどうかだけでなく、どの版、どの設定、どの入力で得られたかを残します。biome の README にある説明と、実際の標準出力、エラーログ、生成物を同じ記録へまとめれば、再現できない印象評価を避けられます。

判断を分ける単位は、開発者の手元で動くこと、CI または管理画面で期待した状態になること、障害後に元の状態へ戻せることです。biome がこの三つを満たすかは環境依存なので、素材にない保証を加えず、自分の代表ケースで確認した範囲だけを採用記録に残します。

入力と出力の対応を残すと、biome の紹介文と実際の挙動を区別できます。試験日、commit または release tag、設定ファイルの hash、実行したコマンド、終了時のログを一組にして保存します。設定を変えた場合は前の結果を消さず、変更点と結果を別行に記録します。

この確認で分かるのは、記録した環境における適合性です。別の OS、端末、入力形式、ネットワーク条件へ結果を広げるときは、同じ観察点を再実行します。公式資料に記載のない保証は追加せず、未確認の条件を採用範囲から外すことが、biome を扱う際の明確な判断になります。

版を変えた結果は旧版と混ぜずに保管し、biome の変更点を確認します。

編集部の結論

Biome は JavaScript や TypeScript の整形と静的検査を一つの設定と CLI で管理したいチームに向きます。採用前に対象リポジトリの既存 formatter と linter の結果を保存し、Biome の設定ファイル、CLI の終了コード、CI 出力、生成差分を比較してください。対応範囲にない言語や既存ルールの細部は、README の記載だけで置き換えない判断が必要です。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes