ESLintの「死の遅延」を可視化せよ：パフォーマンスプロファイリングでCIのボトルネックを特定する
こんにちは。開発環境の設計を専門にしているエンジニアです。
多くのプロジェクトが成長するにつれ、開発者が一度は直面する「悪夢」があります。それは、`npm run lint` を叩いてからコーヒーを淹れに行っても戻ってきてもまだ終わらない、あの忌々しい待ち時間です。
ESLintは強力なツールですが、複雑なルールやプラグインを重ねすぎると、解析処理は指数関数的に重くなります。特に、CI（継続的インテグレーション）環境での遅延は、チーム全体の開発サイクルを著しく阻害します。
今回は、「なぜそのLintは遅いのか？」を科学的に突き止める、ESLintの標準プロファイリング機能について解説します。これを知れば、あなたはもう「なんとなく重い」という曖昧な悩みから解放されます。
—
1. なぜ「静的解析」にプロファイリングが必要なのか？
ESLintは、ソースコードをAST（抽象構文木）に変換し、登録されたルールを一つずつ適用していく「探索的処理」を行っています。もし、特定のプラグインが「巨大なファイル」に対して「コストの高い正規表現」や「型情報の深い参照」を行っていれば、そこがボトルネックになります。
多くのエンジニアは「ルールを減らす」という対症療法で解決しようとしますが、それは間違いです。 真に解決すべきは、「どのルールが、どのファイルに対して、何ミリ秒消費しているか」という真実を知ることなのです。
—
2. プロファイリングの実行：真実を可視化するコマンド
ESLintには、実行結果を詳細に記録する隠れた名機能 `–profile` が存在します。まずは、あなたのプロジェクトで以下のコマンドを実行してみてください。
プロジェクト全体を解析し、各ルールの処理時間を計測する
npx eslint . –ext .ts,.tsx –profile
このコマンドを叩くと、コンソールに以下のような結果が出力されるはずです。
Rule | Time (ms) | Relative
——————————-|———–|———-
@typescript-eslint/no-explicit | 450.23 | 45.2%
import/no-cycle | 320.10 | 32.1%
no-unused-vars | 150.50 | 15.1%
…
ここで注目すべきは `Time (ms)` と `Relative` です。全体の処理時間の大部分を占めているルールが、今のあなたのプロジェクトにおける「犯人」です。
—
3. さらに深掘り：–format table での詳細分析
単なる順位だけでは足りない場合、詳細なレポートを出力させることができます。CI環境で特定のプラグインがどれだけ負荷をかけているかを特定するには、以下の手順が非常に効果的です。
手順①：プロファイル結果をファイルに保存する
実行時間が長い場合は、出力をログファイルにリダイレクトして解析します。
プロファイル結果を profile-report.txt に保存する
npx eslint . –profile > profile-report.txt
手順②：ルールのコスト対効果を判断する
ここで見えてくるのは、「本当にそのルールは必要か？」 という問いです。
例えば、`import/no-cycle`（循環参照のチェック）は非常に強力ですが、巨大なプロジェクトでは解析コストが極めて高くなります。もしこのルールが全実行時間の50%を占めているなら、開発環境では無効化し、CIの時だけ有効にする、あるいは特定モジュールだけに制限するなどの戦略的判断が必要になります。
—
4. 現場で役立つ「高速化」の鉄則
プロファイリングで犯人が特定できたら、以下の改善策を検討してください。
- ルールを絞る: プロファイリングで「遅いのに見つからない（違反が出ない）」ルールは、オーバーヘッドになっている可能性が高いです。
- ファイル除外の最適化: `.eslintignore` を見直し、解析不要なビルド成果物やテストデータが混入していないか確認してください。
- キャッシュの活用: 次のコマンドでキャッシュを有効化し、変更があったファイルだけを解析するように設定します。
キャッシュを有効にして、差分のみを解析する
npx eslint . –cache –cache-location .eslintcache
—
5. まとめ：ツールを「支配」する側に回ろう
開発ツールに振り回されるのは今日で終わりにしましょう。`–profile` オプションを使いこなすことで、あなたは「感覚」ではなく「データ」に基づいて開発環境を最適化できるようになります。
今日のミッション：
1. 自分のプロジェクトで `npx eslint . –profile` を実行してみる。
2. 最も時間のかかっているルール上位3つを確認する。
3. そのルールが本当にプロジェクトの品質に直結しているかをチームで議論する。
これをマスターすれば、毎日のコーディングにおける「待ち時間」という名のストレスが劇的に減り、より本質的なコードを書く時間に集中できるようになりますよ。
エンジニアリングの本質は、常に「測定」にあります。ぜひ、あなたのプロジェクトでも試してみてください。それでは、快適な開発ライフを！