ESLint 設定地獄にサヨナラ。 Biome 移行の全記録

「設定」 より 「コード」 を。僕らが求めていた開発体験

プロジェクトを新しく立ち上げるたび、僕たちは「儀式」のように設定ファイルをコピー & ペーストしてきました。

.eslintrc.js、.prettierrc、.eslintignore、そして最近では eslint.config.js への移行対応……。

依存関係の競合、プラグインのバージョン不整合、Prettier とのルール衝突。

「あれ、なんでこのルール効かないんだ？」
「また Parsing error か...」

本来、僕たちが情熱を注ぐべきは「価値あるプロダクトを作ること」のはずです。しかし、気づけば「開発環境を整えること」に貴重な時間と精神力を削られていました。

かつての僕もそうでした。複雑怪奇な設定ファイルと格闘し、それを「エンジニアのたしなみ」だと自分に言い聞かせていたのです。

しかし、Biome と出会って、その考えは一変しました。

これは、長年連れ添った ESLint / Prettier という「重厚な装備」を脱ぎ捨て、Biome という「軽快な翼」を手に入れた、一人のフリーランス開発者の記録です。

終わらない 「設定ファイル」 との戦い

フリーランスとして複数のプロジェクトを並行して進めていると、環境構築のコストは死活問題です。

特にフロントエンド開発において、Linter（静的解析）と Formatter（コード整形）のセットアップは避けて通れません。長らくのデファクトスタンダードは ESLint と Prettier の組み合わせでした。

これらは素晴らしいツールです。

間違いなく、Web 開発の品質を支えてきました。
しかし、その「柔軟性」ゆえに、設定は年々複雑化していきました。

依存関係の泥沼

気づけば package.json の devDependencies は数十行に膨れ上がり、どれか一つでもバージョンが上がると、謎のエラーログがターミナルを埋め尽くす。

僕はいつしか、動いている設定ファイルを「秘伝のタレ」として崇め、中身を理解しないままコピペするようになっていました。

それは技術者として、どこか後ろめたい行為でした。

転機は 「Rust 製」 の衝撃

そんな時、X（旧Twitter）のタイムラインで Biome（当時は Rome）の話題を目にしました。

最初は半信半疑でした。
「長年のエコシステムを持つ ESLint に勝てるわけがない」と。

しかし、「爆速」という言葉には抗えない魅力がありました。
CI（継続的インテグレーション）の待ち時間に珈琲を飲むのは好きですが、ローカルでの保存時のラグは、思考のフローを断ち切るノイズでしかないからです。

試しに、個人開発の小さな Next.js プロジェクトで導入してみました。

コマンド一発。

npm i -D --save-exact @biomejs/biome

そして実行。

npx @biomejs/biome format --write ./src

...一瞬でした。
瞬きする間に、全ファイルのフォーマットが完了していたのです。

「えっ、これだけ？」

拍子抜けするほど簡単でした。そして何より、速い。
体感ですが、Prettier の 10 倍、いやそれ以上の速さです。

「捨てる」 ことで得た自由

その瞬間、僕は決心しました。
「秘伝のタレ」を捨てる時が来たと。

複雑な .eslintrc.js も、.prettierrc も、大量の npm パッケージも、すべて削除しました。

プロジェクトのディレクトリがスッキリとし、心なしか僕の頭の中の霧も晴れたような気がしました。

Biome は、「設定」ではなく「規約」を重視します。

細かすぎるカスタマイズはできませんが、「モダンな Web 開発における正解」 が最初から用意されているのです。

「これでいいんだ。いや、これがいいんだ」

僕たちは、設定ファイルの管理人ではありません。コードで世界を変えるクリエイターなのですから。

Biome 移行の実践ログ

ここからは、実際に僕が Next.js (TypeScript) プロジェクトを ESLint / Prettier から Biome に移行した際の手順と、現在運用している設定ファイルをそのまま公開します。

「興味はあるけど、移行でハマりたくない」
「VSCode の設定はどうすればいいの？」

そんな不安を解消できるよう、ステップバイステップで解説します。