Prettierは「整形ツール」ではない。CIとIDEを加速させる「開発インフラの心臓部」である。
多くのエンジニアが、Prettierを「保存時にコードを綺麗にしてくれる便利なやつ」と認識している。だが、大規模プロジェクトのテックリードの視点で見れば、それは極めて危険な認識だ。
Prettierは、設定を誤ればCIを数分遅延させ、IDEのインデックス生成を阻害し、チームの生産性を奪う「ボトルネック」にもなり得る。今回は、単なる除外リストだった`.prettierignore`を、開発体験（DX）を最大化する戦略的兵器へと昇華させる極意を伝授する。
—
1. .prettierignoreの「真の役割」を理解する
`.prettierignore`の役割は「整形したくないファイルを除外すること」ではない。「解析対象から物理的に切り離すことで、静的解析コストをゼロにすること」だ。
生成コードとバイナリの「完全遮断」
自動生成されたコード（`dist/`, `.next/`, `graphql-codegen`の出力など）を放置すると、Prettierはそれらに対しても解析の試行を繰り返す。これはCPUリソースの無駄遣いであると同時に、IDE（VS Codeなど）でファイルを開くたびにPrettierがバックグラウンドで走り、フリーズの原因となる。
実務におけるベストプラクティス設定例:
— ビルド・成果物 —
dist/
build/
out/
coverage/
— パッケージマネージャーのロックファイル —
これらはPrettierではなく、各ツールで管理すべき
package-lock.json
yarn.lock
pnpm-lock.yaml
— 特殊な自動生成コード —
スキーマから生成された型定義や、ORMのマイグレーションコード
src/generated/
.gen.ts
— バイナリ・アセット —
.png
.jpg
.ttf
.woff
なぜこれが必要か？
Prettierは内部でAST（抽象構文木）を生成する。数万行の自動生成コードをAST化するコストは膨大だ。`.prettierignore`に明記することで、Prettierのメインプロセスからこれらのファイルを「存在しないもの」として扱わせる。これにより、CI実行時間は数秒〜数分単位で改善する。
—
2. CI/CDのパフォーマンスを極限まで引き上げる戦略
CIで `prettier –check` を走らせる際、「対象ファイルの絞り込み」を行っていないチームが多すぎる。プロジェクトルートで全探索させるのではなく、必要なディレクトリのみを指定せよ。
CI実行の最適化コマンド（GitHub Actions等）
全ファイルを対象にするのではなく、変更されたファイル、
もしくはソースコード領域のみをターゲットにする
npx prettier –check “src//.{ts,tsx,js,jsx,json,md,css}”
さらに、「Lint-staged」との併用は必須だ。コミット前のフックで全ファイルを整形するような愚行は避け、変更差分（Staged files）のみを対象にすることで、開発者のローカルストレスを限りなくゼロにする。
—
3. チーム開発を崩壊させない「共有化の掟」
設定ファイルが個人の環境でバラバラになることは、チーム崩壊の第一歩だ。以下の構成を推奨する。
.prettierrc.json のベストプラクティス
{
“semi”: true, // セミコロンの強制（TS環境では必須）
“singleQuote”: true, // シングルクォート統一
“tabWidth”: 2, // インデント幅の統一
“trailingComma”: “all”, // 差分を最小化するためのカンマ
“printWidth”: 100, // モダンなワイドモニターに合わせた幅設定
“bracketSpacing”: true, // オブジェクト内のスペース（可読性向上）
“proseWrap”: “always” // マークダウンの改行もルール化し、Gitの差分を綺麗にする
}
テックリードの視点:
`trailingComma: “all”` は非常に重要だ。これにより、配列やオブジェクトの末尾にカンマが入るため、次の要素を追加した際のGit差分が「1行追加」だけで済む。これが設定されていないと、修正行が複数行に渡り、コードレビューのノイズとなる。
—
4. 開発効率を跳ね上げる「神プラグイン」と設定
絶対に入れるべきプラグイン：`prettier-plugin-sort-imports`
import文の順序を自動でソートするプラグインだ。
npm install –save-dev @trivago/prettier-plugin-sort-imports
これを入れることで、import文の並び順に関する論争は消滅する。コードレビューで「このimport順がバラバラだ」と指摘する時間は、地球上で最も生産性の低い時間の一つだ。
IDEの神設定：VS Code `settings.json`
`”editor.formatOnSave”: true` だけでは不十分だ。以下の設定を加えて、保存時の挙動を最適化せよ。
{
“editor.formatOnSave”: true,
“editor.defaultFormatter”: “esbenp.prettier-vscode”,
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit” // ESLintとPrettierの競合を回避する
},
“prettier.documentSelectors”: [“/.{js,ts,tsx,json,md}”]
}
—
最後に：なぜこれを行うのか
私たちがこうした「静的解析の最適化」を行う理由は、単にコードを綺麗にするためではない。「エンジニアが、コードのロジックやアーキテクチャといった『人間が考えるべき高付加価値な作業』に100%の脳のリソースを割けるようにするため」だ。
コードフォーマットやインポート順序など、ルール化できるものはすべて機械に委ねる。`.prettierignore` を洗練させることは、そのための「聖域」を作る作業に他ならない。
明日、チームのプロジェクトから `.prettierignore` を見直してみてほしい。不要な解析対象を削ぎ落とすだけで、あなたのチームのCIは驚くほど速くなり、開発者はよりクリエイティブな仕事に没頭できるようになるはずだ。