大規模リポジトリを「爆速」に変える：ESLintとPrettierの限界突破チューニング術
こんにちは。開発環境アーキテクトとして、これまで数百万行規模のモノレポからスタートアップのプロトタイプまで、数多のプロジェクトを渡り歩いてきました。
プロジェクトが成長するにつれ、皆さんが必ず直面する「壁」があります。そう、「Lint実行時間が長すぎて、コミットするたびにコーヒーを淹れに行く時間ができてしまう」という問題です。
Lintは本来、開発者の思考を止めないための「守護神」であるべきです。数分待たされるLintは、もはや開発速度を削ぐ「足かせ」でしかありません。今日は、ESLintとPrettierを極限までチューニングし、大規模リポジトリでも一瞬でフィードバックを得るための「アーキテクトの極意」を伝授します。
—
1. なぜLintは重くなるのか？その本質を理解する
まず、Lintが重くなる理由は単純です。「毎回、全ファイルを解析しているから」です。
特にTypeScriptのプロジェクトでは、型情報に基づいたLint（`parserOptions.project`を使用する場合）を実行すると、ツールは全ファイルの依存関係ツリーを再構築します。これを毎回ゼロからやるのは非効率の極みです。
ここで導入すべきは「差分のみを処理する」という概念です。
ESLintのキャッシュ機能を「賢く」使う
`–cache`オプションは知っている方も多いでしょう。しかし、デフォルトのままだとキャッシュの保存場所や対象が不明瞭になりがちです。以下のように設定を強化しましょう。
// package.jsonのscriptsを書き換える
{
“scripts”: {
// –cache: 変更がないファイルは解析しない
// –cache-location: .eslintcacheを明示的に指定してGit管理外にする
// –cache-strategy: ‘content’を指定し、ファイル名ではなく内容のハッシュ値で判定する
“lint”: “eslint . –ext .ts,.tsx –cache –cache-location .eslintcache/ –cache-strategy content”
}
}
アーキテクトの視点: `–cache-strategy content`は必須です。ファイル名の変更やタイムスタンプの揺らぎに左右されず、コードの内容そのものを見て判定するため、キャッシュの信頼性が劇的に向上します。
—
2. lint-staged を使った「必要な場所だけ」の集中攻撃
大規模プロジェクトでは、全ファイルLintはCIに任せ、ローカル開発では「今触っているファイル」だけをLintするのが鉄則です。ここで登場するのが `lint-staged` です。
爆速チューニングの設定例
多くの人がやってしまいがちなのが「全ファイルに対するPrettier実行」です。これを避ける設定がこちらです。
// .lintstagedrc.json
{
“.{js,ts,tsx}”: [
“eslint –cache –fix”,
“prettier –write”
]
}
ここで重要なポイントは、「ESLintで`–fix`をかけ、その直後にPrettierを当てる」という順序です。ESLintはコードの修正を伴うことがありますが、その後の整形をPrettierに一任することで、ルールの衝突を防ぎつつ、高速にクリーンなコードを維持できます。
—
3. 不要なファイルを除外する「ブラックリスト」の魔術
ESLintが「node_modules」や「dist」などの不要なファイルまで覗きに行くと、解析速度は目に見えて低下します。`.eslintignore` を徹底的に管理しましょう。
.eslintignore
ビルド成果物や依存関係は解析対象外
dist/
build/
node_modules/
プロジェクト固有の生成ファイル
.min.js
coverage/
設定ファイルなどは除外対象外にして、コードベースに集中させる
アーキテクトの視点: `.eslintignore` の記述を怠ると、ESLintは数万行のライブラリコードまで解析しようとします。ここを絞るだけで、体感速度は30%以上向上します。
—
4. 精度高い「HelloWorld」的動作確認
設定が正しく効いているか、以下の手順で「爆速化」を体感してください。
1. 初回実行: `npm run lint` を実行。初回はキャッシュ生成のため時間がかかります。
2. キャッシュ確認: プロジェクトルートに `.eslintcache/` フォルダが生成されたことを確認します。
3. 爆速化の実感: 再度 `npm run lint` を実行してください。全ファイルがチェック対象であっても、一瞬で終了するはずです。
動作確認コマンド
実行時間の計測を行う（Linux/macOSの場合）
time npm run lint
初回は5秒かかっていた処理が、2回目以降は0.5秒以下になる。この「0.5秒のフィードバック」が、あなたの開発体験を劇的に改善します。
—
最後に：ツールに振り回されるな、ツールを飼い慣らせ
大規模開発において、エンジニアの最大の資産は「集中力」です。Lintの待ち時間にスマホを見てしまうような環境を放置してはいけません。
今回紹介したキャッシュ戦略や並列実行の考え方は、単なる設定の変更ではなく、「開発というプロセスを最適化するアーキテクトの思想」そのものです。
まずは今日、あなたのプロジェクトの `package.json` にこの設定を加えてみてください。毎日のコーディングが、今よりも少しだけ軽快で、楽しいものになるはずです。もし設定で詰まったら、いつでも聞いてくださいね。あなたのコードが最高の品質で、最高の速度でリリースされることを心から応援しています！