はじめに

こんにちは。
レバウェル開発部アドベントカレンダー24日目担当の村山です。

私たちのチームではスカウトサービスを開発しており、大規模なリファクタリングを進めています。
リファクタリングやテスト拡充によるソースコードの増加に伴って、フォーマッター・リンターの開発者体験低下しているのでは？という懸念がチーム内で浮上しました。

この課題を解決するために、私たちは「Biome」を導入を検討・決定しました。
本記事では、導入背景、意思決定のプロセス、導入後の結果ついてご紹介します。

1. そもそもBiomeってなに？

Biomeは、次世代のコードフォーマッター兼リンターです。
従来の開発環境では、コードの整形や静的解析には主にESLintやPrettierといったツールが使用されてきましたが、これらの設定や運用には多大な労力が伴うことがあります。
Biomeは、これらの課題を解決するために生まれたオールインワンツールです。

Biomeの特徴は以下です。

高速な処理: Rustで実装されており、従来のJavaScriptベースのツールよりも高速に動作します。
統合性: フォーマッターとリンターが一体化しており、ESLintやPrettierを個別に設定・運用する必要がありません。
設定不要: 初期設定が不要で、プロジェクトに簡単に導入できます。

Biomeは、単なる便利ツールではなく、開発者体験（DX）を向上させるために設計されています。特に、複数のツールを組み合わせて設定・運用する手間を軽減し、チーム全体で一貫したコーディングスタイルを維持しやすくすることを目的としています。

2. なぜBiomeを導入しようと思ったのか？

2.1 開発者体験の低下

リファクタリングやテスト拡充が進む中で、フォーマットやLint処理にかかる時間が徐々に増加していました。
当時はまだ少し気になるレベルでしたが、フォーマッターやリンターの遅延は開発者の生産性低下を引き起こし、長期的に見た時にストレスの原因になります。

2.2 フォーマッターとリンターの管理

これまではESLintとPrettierを併用していましたが、「一元管理できたら嬉しいよなぁ」という想いもチーム内にありました。
こちらはマストではないけどできたら嬉しいよねくらいの温度感でした。

Biomeなら上記の課題を解決できそう！ということで導入の検討が始まりました。

3.Biome導入のための調査・検討・意思決定

3.1 調査

私たちのプロダクトでは、ESLintとPrettierを併用しています。
これらのルールを全てBiomeで置き換えられるのか。それを初めに調査してみました。

結論から言うと、完全に移行するのは不可能だということがわかりました。
Prettierは完全に置き換え可能でしたが、ESLintで設定している一部の独自ルールはBiomeで置き換えできないためです。（Biomeなんでカスタムルール使えないのぉ...）

ESLintとのルール互換は下記を元に調べました。
今はコマンドでも変換できるようなので、そちらを試してみるのも良いかもです。

3.2 検討

調査結果を踏まえて、以下の3つの選択肢をチーム内で検討しました。

案	実行速度	設定ファイル　・ライブラリ	細かなルール設定	挙動の安定性
① Biomeのみ	⚪︎ 速い	⚪︎ 減らせる	× 設定できない	△ 不安あり
② Biomeと一部ESLint併用	⚪︎ そこそこ速い（はず）	× 複数必要	⚪︎ 設定できる	△ 不安あり
③ Prettier　とESLint併用	× 速くない	× 複数必要	⚪︎ 設定できる	⚪︎ 安定

3.3 意思決定

結果として、私たちのチームでは「② Biomeと一部ESlintの併用」を採用しました！

判断の理由は以下です。

実行速度を速くしたい
カスタムルールを設定したい
開発が活発なため、もしBiomeの挙動が不安定でもすぐに改善されるでは？という期待感
複数のライブラリと設定ファイルが必要だけど、それはまあいいでしょう
新しい技術を積極的に採用していきたい

4. Biomeを導入してみた

4.1 導入方法

公式の以下の手順を参考にして導入しました🚀

Formatterについては、これまでのPrettierのルールをそのまま置き換えました。

Linterについては、全てのルールを有効化し、現在のチームの運用に沿わない一部ルールのみ選択的に無効化する方法を取っています。現状はソースコードの実態に合わせて、部分的にignoreしている箇所もあります。
（ちなみにお試し導入であれば、推奨ルールのみ有効化でも良いかなと個人的には思います。）

4.2 BiomeとESlintとの併用

基本的にはBiomeがフォーマットとリンターのほとんど担っており、一部ESLintルールのみ残しています。

ESLintで残しているカスタムルールは以下です。
これらはチームで話し合い、現段階では必要だという判断をしました。

import順の管理
- コードの可読性と統一感を維持するため
- Biomeにもimport順序に関するルールは一応あるが、私たちにとっては不十分

import元の制限:
- 特定のimportを制限したいため

4.3 気になる実行速度

以下が導入前後のformatter&Linterの比較です！
※対象ファイルは1900程度
※前後どちらも

比較項目	導入前	導入後
使用ライブラリ	Prettier ESLint	Biome 一部ESLint
実行時間	107.68秒	0.88秒

約122倍速くなりました！！！！🥳
公式HPのトップでは、Prettierとformatterとして比較して最大35倍と公表されていますが、LinterまでBiomeに任せることでさらに効果的だということがわかりました。

4.4 使ってみて困っている点

バージョンが、最新でv1.9.4(12/21現在)とまだ若いライブラリのため、たまにバグることがあります。
が、バージョンアップは頻繁にあるので、そこは今後の改善へ期待です。

同じ開発グループ内の別のチームは、Biomeへ完全移行している(ESLintとの併用なし)チームもあり、そこでも大きな問題にはなっていないため、実用に耐えるかなと言う所感です。

まとめ

今回は私たちのチームがBiomeを導入するに至った背景からその結果までを振り返りました。

BiomeとESLintを併用することで、FormatterとLinterの実行速度は速くしつつ、カスタムルールの柔軟性も保つことができ、当初の課題を解決することができました🚀

Biomeはほとんどの開発チームにお勧めすることができる選択肢になると思います。
個人開発であれば、個人的にはもうBiome一択かなと感じています。

今回の記事が、LinterとFormatterの実効速度に悩める方や、Biomeの導入を検討している人の参考になれば幸いです。