iimon TECH BLOG

iimonエンジニアが得られた経験や知識を共有して世の中をイイモンにしていくためのブログです

まだESLintとPrettier使ってるの?(Biomeを試してみた!)

はじめに

こんにちは! 株式会社iimonでエンジニアをしている「あめく」です。

今回は最近注目を集めてきてる?JavaScriptやTypeScript等で使用する静的解析とフォーマッターを備えたツール Biome を試してみたので紹介したいと思います!

まず静的解析とは

静的解析(static code analysis)とはコードを実行せずに行なう検証のことで、ソースコードを解析してプログラミング言語の文法や仕様を満たしているか、 定められたコーディング規約(コーディングパターンやルール)に則っているかなどを調べることをいいます。

一方、実際にプログラムを実行してみて問題が発生しないか確かめることは動的解析(dynamic analysis)と呼ばれます。 ソフトウェアのテストと言えばこちらを指すことが多いかと思います。

現在のデファクトスタンダード

JavaScriptやTypeScriptだとおそらくESLintを用いて静的解析を行ってるかと思います。 また、フォーマットに関してはESLintのフォーマッターでは対応しきれないこともあるためフォーマットに特化したPrettierと併用することがデファクトスタンダードになってるかと思います。
弊社の各サービスのコードでもリンターとフォーマッターにはESLint+Prettierを用いてることが大半です。(調べてないです!)

このデファクトスタンダードに対抗してきたツールが今回ご紹介するBiomeです!

Biomeとは

簡単にいうとESLintとPrettierを一つにしたツールです。

BiomeのサイトによるとBiomeはTypeScriptやTSX等の高速フォーマッターであり、Prettierとの互換性が97%あるそうです。 Intel Core i7 1270Pで2,104個のファイル内の171,127行のコードをフォーマットする場合、Prettierよりも35倍高速だそうです。
※ 参考URL: https://biomejs.dev/

他社でも実行の速さやPrettierとの互換性、Lintルールも一通り対応されてるとのことからBiomeに移行する流れがでてきています。 ただ、まだESLintの機能に対して足りてない部分があるため併用したりしてるみたいです。
https://tech.toreta.in/entry/2024/10/16/フロントエンド開発環境スタートセット2024秋

ちなみにPrettierのメンテナーの人がBiomeの歴史やESLintとの比較について記事にしてるので読んでみると面白いのでぜひ! https://zenn.dev/sosukesuzuki/articles/756e04848885bd

Biomeを触ってみての感想とESLintとの比較

Biomeでは現状、特定のファイルに対して特定のルールを適応、除外することができないみたいです。

Next.jsとTailwindCSS+shadcn/uiの構成でBiomeを試した際にtailwind.config.tsファイルがライブラリ特有の書き方でルールに乗っ取っていないことがあり、このファイルだけ対象のルールを除外したかったのですがBiomeではできなさそうでした。

ちなみに特定のファイルに対して全ルールを除外することは可能でしたが、全ルール除外となるとちょっと困るなという感じです。。。 ただ、configファイルに対して静的解析をしないなどルールを決めたり特定の行に対してルールを無効化することも可能なのでやりようはあるかと思います。

ESLintではoverridesの設定を用いれば、特定ファイルのみ適用外にすることが可能なのでこの点に関してはESLintが使い勝手が良さそうな印象を受けました。

せっかくですので、Reactで開発された社内のサービスでESLint+PrettierとBiomeを実行して速度を測ってみました!

  • とあるサービスの状況
全ファイル数: 746ファイル
全ファイルの行数: 298,450行
.tsと.tsxファイル数: 597ファイル
.tsと.tsxファイルの行数: 110,442行
  • 実行速度の確認

ESLintの場合

Program : npx eslint src/
CPU     : 58%
user    : 0.615s
system  : 0.179s
total   : 1.367s

Biomeの場合

Program : npx @biomejs/biome check --write src/
CPU     : 241%
user    : 1.167s
system  : 0.159s
total   : 0.550s

total結果を見るとESLintを用いるよりも約1/3の速度で実行できてそうです。
※ Biomeは並列処理のためuserの秒数が大きくcpuの割合も高くなってる。

Biomeを実際に試してみよう!

下記コマンドでディレクトリ作成してディレクトリ移動する。
npm initを行う。

$ mkdir biome-test
$ cd biome-test
$ npm init -y

npmでBiomeをインストール。

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

ドキュメント

Biomeインストールコマンド

Biomeを初期化してbiome.jsonファイルを作成する。

$ npx @biomejs/biome init

main.jsファイルを作成する。

$ touch main.js

main.jsに下記のコードを記載してBiomeを試していきます!
※ あえてコードは崩れてます。

const
sum = function(a, b) {
  return a + b;
};



let hoge  =                   100



export           {
    hoge
    as                       hoge

}
フォーマッター
 npx @biomejs/biome format main.js

formatエラー

  • フォーマットしてくれるコマンドを実行すると対象のコードがフォーマットされます。
    (コマンドのオプションに --write をつける)
npx @biomejs/biome format --write main.js
const sum = function (a, b) {
    return a + b;
};

let hoge = 100;

export { hoge as hoge };
リント機能
  • リントのチェックのコマンドを実行すると対象のコードがエラーになります。
npx @biomejs/biome lint main.js

lintエラー

  • リントチェックして修正してくれるコマンドを実行すると対象のコードがフォーマットされます。
    (コマンドのオプションに --write をつける)
npx @biomejs/biome lint --write main.js
const
sum = (a, b) => a + b;



const hoge  =                   100



export           {
    hoge

}
フォーマッターとリントの同時実行
  • リントとフォーマットをチェックするコマンドを実行するとリントとフォーマットエラーになります。
npx @biomejs/biome check main.js

lintとformatエラー

  • リントとフォーマットをチェックして修正してくれるコマンドを実行すると対象のコードが修正されます。
    (コマンドのオプションに --write をつける)
npx @biomejs/biome check --write main.js
const sum = (a, b) => a + b;

const hoge = 100;

export { hoge };

別途Gitのフック管理について

ESLintとPrettierを用いた場合、おそらくHuskyとlint-stagedを用いてコミット時に静的解析を実行してコミットに不要なコードを取り込まないようにしてる方が多いかと思います。(ciでやったり)

Biomeを用いる場合、Lefthookというツールを持ちいることですぐに環境を作ることが可能となります!

下記のドキュメントに設定方法が記載されてるので、こちら試したい方はぜひやってみてください!
結構簡単に設定できます!
https://biomejs.dev/ja/recipes/git-hooks/

まとめ

今回Biomeを使ってみて感じたことはESLint+Prettierよりも導入がサクッとできる印象です!

また、今までの構成だとGitのフック管理も含めるとPrettier, ESLint, Husky, lint-stagedを用いるのがデファクトスタンダードかと思いますが、 BiomeとLefthookを用いれば管理するツールも少なくなるため、設定の記述も少なくなったりバージョンが上がった際の影響範囲も少なくなります。 また実行速度も早くなるため、色々とメリットがありそうなので移行を検討するのはありかと思います。

ひとつ懸念があるとすれば、まだまだ発展途上のツールですので今後どうなるのかの不安と、 まだESLintのルールがカバーされてない部分もあるためESLintとの併用が必要になる可能性があるくらいかと思います。 ルール一覧

もし何か間違ってる内容などあればご指摘ください。。

ぜひ皆さんも静的解析やフォーマットの自動化で素敵なフロントライフをお楽しみください!

ここまで読んでくださってありがとうございました。

また、弊社ではエンジニアを募集しております。 ぜひカジュアル面談でお話ししましょう!

ご興味ありましたら、ご応募ください!