Prettierのフォーマットコストを「ゼロ」にする：大規模リポジトリにおけるインクリメンタル戦略の極意
「保存するたびに重いPrettierが走るのを待つ時間」――この数秒の積み重ねが、エンジニアのフロー状態をどれだけ阻害しているか考えたことはありますか？
大規模リポジトリにおいて、`prettier –write .` をCIで走らせたり、保存時に全ファイルを走査させる設定は、もはや「技術的負債」です。我々アーキテクトが目指すべきは、「フォーマットの存在を意識させない」環境です。
本稿では、Gitのメタデータを活用し、差分のみを外科手術のように整形する「インクリメンタル・フォーマット」の真髄と、それをチーム開発の標準にするための設計思想を伝授します。
—
1. なぜ「全量フォーマット」は悪なのか
Prettierの実行コストは、単なるCPU使用率の問題ではありません。「Git履歴の汚染」と「コンテキストスイッチの発生」が最大の問題です。
- Git履歴の汚染: 意味のない全量フォーマットは `git blame` を破壊します。コードの意図を追いたいときに、フォーマット変更のコミットが邪魔をするのは、開発者体験（DX）として最悪です。
- 非決定的な待ち時間: ファイル数が増えるほど、Prettierの走査時間は非線形に増大します。これをIDEの保存時フックにフックさせると、タイピングのテンポが崩れます。
—
2. 実践：インクリメンタル・フォーマットのアーキテクチャ
フォーマットすべき対象は、常に「今、作業しているファイル」と「変更されたファイル」だけです。これを実現するための3層防衛線を構築します。
第1層：Git Stagedでの強制（lint-staged）
コミット直前に、変更分のみを確実にフォーマットします。`husky` と `lint-staged` の組み合わせは基本ですが、設定を最適化します。
// .lintstagedrc.json
{
// 変更されたTS/JSファイルのみを対象に実行
“.{js,jsx,ts,tsx}”: [
“prettier –write –cache”,
“eslint –fix”
],
// その他のファイルもフォーマット対象に含めることで、リポジトリの整合性を保つ
“.{json,md,yml}”: [
“prettier –write –cache”
]
}
ポイント: `–cache` オプションを忘れないでください。Prettierは内部的にハッシュ値を生成し、前回の結果と照合します。これにより、変更されていないファイルへの再計算を完全にバイパスできます。
第2層：IDE保存時の「差分最適化」
VS Codeの「保存時にフォーマット（Format on Save）」は強力ですが、全ファイルに走ると危険です。`.editorconfig` を活用し、「保存時に変更行のみを整形する」設定を徹底します。
VS Code設定（settings.json）:
{
“editor.formatOnSave”: true,
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit” // ESLintのfix機能のみを明示的に実行
},
“editor.formatOnSaveMode”: “modifications”, // 重要：変更された行のみを対象とする設定
“[javascript][typescript]”: {
“editor.defaultFormatter”: “esbenp.prettier-vscode”
}
}
`”editor.formatOnSaveMode”: “modifications”` は、ファイル全体を解析してもフォーマットの適用範囲をGitの変更差分に限定するため、巨大ファイルでも一瞬で終わります。
—
3. 神プラグインとTips：開発効率を限界突破する
必須プラグイン: `prettier-plugin-sort-imports`
import文の整理に悩みたくないなら必須です。
npm install –save-dev @trivago/prettier-plugin-sort-imports
これを導入すると、開発者はimportの順序を気にする必要がなくなります。自動的に「外部ライブラリ -> 内部エイリアス -> 相対パス」の順にソートされ、コンフリクトの温床を根絶します。
隠れたキーボードショートカット
VS Codeの「コマンドパレット」から `Format Document` を叩くのはやめましょう。
- `Ctrl + K` -> `Ctrl + Shift + F` (Win/Linux)
- `Cmd + K` -> `Cmd + Shift + F` (Mac)
これらで「現在の選択範囲のみ」フォーマットできます。特定関数だけを綺麗にしたい時に、ファイル全体を触らずに済みます。
—
4. チーム開発における「設定の共有」と「衝突回避」
チームで最も避けたいのは、「人によってフォーマットが異なる」ことによる無駄な修正コミットです。
.prettierrcのベストプラクティス
.prettierrc.yaml
semi: true # 文末セミコロンは必須（ランタイムエラー防止）
singleQuote: true # シングルクォート統一
trailingComma: ‘all’ # 差分が分かりやすくなるため必須
tabWidth: 2
printWidth: 100 # 80は狭すぎる。現代のワイドモニターでは100-120が最適
チームへの強制力：`.prettierignore` の活用
設定ファイル以上に重要なのが無視設定です。
.prettierignore
ビルド成果物や生成ファイルは絶対にフォーマットしてはいけない
dist/
build/
coverage/
package-lock.json # 依存関係のファイルはPrettier管理対象外
—
アーキテクトからの提言
「フォーマットの自動化」は、単なる見た目の統一ではありません。「コードの変更という概念を、人間が理解しやすい差分のみに限定する」ための知的なコスト削減です。
もし、今あなたのプロジェクトで保存時に「重い」と感じるなら、それはツールがファイルを過剰に処理している証拠です。`–cache` を使い、`modifications` モードを有効にし、Gitの力を借りて、「必要な場所だけを最適化する」。この習慣が、数ヶ月後のあなたのプロジェクトの生産性を数倍に引き上げます。
さあ、今すぐ設定ファイルを書き換え、無駄な待ち時間を消し去ってください。エンジニアの時間は、タイピングの整理に使うにはあまりにも貴重なのですから。