Prettierの待ち時間は「悪」。巨大リポジトリでコード整形コストをゼロにする戦略的アーキテクチャ
こんにちは。開発環境の最適化こそがエンジニアの寿命を延ばすと信じているアーキテクトです。
大規模なプロジェクトで`npm run format`を叩いて、数分間PCが唸りを上げるのを眺めた経験はありませんか？あるいは、ファイルを保存するたびにIDEがラグを起こして思考が途切れる……。これらは単なる「待ち時間」ではなく、開発者の集中力（フロー状態）に対する重大な攻撃です。
今日は、Prettierという強力なツールを「強制的な重石」から「透明な背景プロセス」に変えるための、インクリメンタル・フォーマット（差分のみの整形）の実装手法を伝授します。
—
1. なぜ「全体フォーマット」は悪手なのか？
プロジェクトが成長すると、全ファイルを走査するコストは指数関数的に増大します。特にCI/CDパイプラインにおいて全ファイルを整形するのは非効率の極みです。
私たちの目標はシンプルです。
「自分が触った行だけ」を「最速で」整形し、それ以外のコードには1ミリも干渉しない。 これが実現できれば、巨大リポジトリであってもフォーマットコストは常にゼロになります。
—
2. 実践的セットアップ：lint-stagedによる「ステージング領域限定」フォーマット
まずは、コミット直前に「Gitのステージング領域（変更分）」のみを対象にする仕組みを入れます。
必要なライブラリのインストール
husky: Gitフックを管理するツール
lint-staged: ステージングされたファイルのみを実行対象にするツール
npm install –save-dev husky lint-staged
設定ファイルの構成 (.lintstagedrc.json)
プロジェクトルートに以下の設定を置きます。ここでのポイントは、「TS/JSファイルのみを絞り込み、Prettierを実行する」という一点です。
{
“.{js,ts,jsx,tsx}”: [
“prettier –write”
// 変更されたファイルだけを対象にフォーマット。全走査は行わない
]
}
これで、あなたが `git add` したファイルだけがコミット前に整形されます。
—
3. IDEの最適化：保存時のラグを「視界から消す」
多くの人がやりがちなのが、IDEの「保存時に全ファイル整形」設定です。これは巨大リポジトリでは致命的です。VSCode等の設定は「変更した範囲のみ」に限定しましょう。
`.vscode/settings.json` に以下の設定を書き込みます。
{
“editor.formatOnSave”: true,
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit”
},
“prettier.documentSelectors”: [“/.{js,ts,jsx,tsx}”]
// 特定の拡張子に絞ることで、検索対象のインデックスを軽くする
}
ここが重要： Prettierにはキャッシュ機能があります。`–cache` オプションを活用しましょう。
package.jsonのスクリプト例
“format”: “prettier –write . –cache”
`–cache` をつけることで、Prettierは `.prettiercache` ファイルを参照し、前回の実行から変更がないファイルをスキップします。これで、万が一全走査が必要な場合でも、速度は劇的に向上します。
—
4. エッジケースの攻略：なぜ「順序」が命なのか
現場でよくあるトラブルが、「ESLintの自動修正」と「Prettierの整形」の衝突です。これらが競合すると、保存のたびに無限ループのようにコードが微修正され続け、IDEがフリーズします。
これを防ぐ唯一の解法は、「ESLintには構文チェックを任せ、フォーマットはPrettierに一任する」という役割分担の徹底です。
eslint-config-prettierを導入し、ESLintのフォーマットルールを完全に無効化する
npm install –save-dev eslint-config-prettier
`.eslintrc.json` の最後尾に以下を追記してください。
{
“extends”: [
“eslint:recommended”,
“prettier” // これが重要。必ず一番最後に書くことで他のルールを上書きする
]
}
—
5. 結論：コードは「書く」ことに集中せよ
今回の設定を適用することで、あなたの開発環境は以下のようになります。
1. 保存時： 変更した箇所だけが数ミリ秒で整形される。
2. コミット時： ステージングしたファイルのみがチェックされ、CIの無駄な待機時間が消滅する。
3. チーム全体： 誰がどのファイルを触っても一貫したフォーマットが保たれ、GitのDiffがクリーンになる。
「ルールを厳しくする」のではなく、「ルールに従うことが最も楽である」という環境を作るのが、優れたアーキテクトの仕事です。
今日から、フォーマットのために時計を見るのはやめましょう。コードを書くことだけに脳のリソースを注ぎ込む。その環境こそが、あなたを一流のエンジニアへと押し上げる最強の武器になります。
何か構築中に不明な点があれば、いつでも相談してください。あなたの開発体験がより快適になることを願っています。