「フォーマットの呪縛」から解放される：ESLint × Prettier のアーキテクチャ最適化戦略
開発の現場において、「コード整形」は単なる見栄えの問題ではありません。チーム全員の脳のリソースを、「コードを書くこと」そのものに集中させるための極めて重要なインフラです。
多くのエンジニアは ESLint や Prettier を入れただけで満足してしまいますが、それは「強力なエンジンを積んだF1カーで、近所のコンビニに買い物に行っている」ようなものです。今日は、特に `.prettierignore` を深掘りし、CI/CDのパイプラインを劇的に加速させ、開発体験を究極まで高める「アーキテクトの視点」を伝授します。
—
1. なぜ「ツールを制御する」必要があるのか？
ESLint（論理的な品質管理）と Prettier（物理的な整形管理）を併用するとき、初心者が陥る最大の罠は「過剰なスキャン」です。
巨大なプロジェクトで、コンパイル済みの生成物や依存関係のキャッシュ、バイナリファイルまでスキャン対象に含めていませんか？ ツールが「何もしなくていい場所」を明確に指示することは、IDEのレスポンス向上とCIのコスト削減に直結するのです。
—
2. 基礎：共存のための最小構成
まずは、両者が喧嘩しないための鉄板設定を確認しましょう。`eslint-config-prettier` は、「ESLintの整形ルールを全てオフにする」という魔法の杖です。
インストールコマンド:
Prettier本体と、ESLintとの衝突を防ぐプラグインを導入
npm install –save-dev prettier eslint-config-prettier
.eslintrc.json の設定:
{
“extends”: [
“eslint:recommended”,
“prettier” // これが重要。ESLintのフォーマット系ルールを無効化する
]
}
これで、「品質はESLint、見た目はPrettier」という分業体制が完成します。
—
3. 奥義：.prettierignore の「戦略的」活用
ここからが本題です。`.prettierignore` を「単なる除外リスト」として使うのは今すぐやめましょう。これは「ツールに無駄な計算をさせないための防波堤」です。
おすすめの `.prettierignore` 定義
— 1. ビルド成果物・キャッシュ —
dist/
build/
coverage/
.cache/
— 2. 依存関係のロックファイル（編集不要） —
package-lock.json
yarn.lock
pnpm-lock.yaml
— 3. 自動生成コード（最重要） —
GraphQLの型定義や、OpenAPIから生成されたクライアントコード
src/generated/
.gen.ts
— 4. 環境固有の設定ファイル —
.env.
なぜこれが必要なのか？
1. ループの回避: 自動生成コードをフォーマットすると、次のビルド時に「差分がある」と見なされ、無限ループ的なビルドエラーや意図しないコミットが発生するリスクがあります。
2. パフォーマンス: `node_modules` は当然ですが、`dist` や `coverage` をスキャン対象から外すだけで、巨大なプロジェクトでは保存時のラグが数秒単位で改善されます。
3. Git履歴の保護: 自動生成されたコードを無理に整形すると、Gitの差分が肥大化し、コードレビューが困難になります。
—
4. 現場で震えるほど役立つ「最適化のコツ」
CIパイプラインでの戦略的実行
CIで `prettier –check .` を実行する際、`–ignore-path .prettierignore` を指定するのは基本ですが、さらに `–cache` オプションを組み合わせることで、「変更されたファイルのみを再スキャンする」という運用が可能です。
CI環境での実行例
–cache: 前回の結果を保存し、差分のみを処理
–write: 修正が必要なら上書きする
npx prettier –write . –cache –log-level warn
IDE（VSCode）のパフォーマンス維持
VSCodeで「保存時にフォーマットする（Format on Save）」を有効にしている場合、設定ファイルで `ignore` が適切に機能しているか確認してください。これを行わないと、巨大なファイルを保存するたびに、裏で何万行ものファイルを解析しようとしてPCがファンを唸らせることになります。
—
結論：ツールを「飼い慣らす」エンジニアへ
今回紹介した `.prettierignore` の最適化は、地味ですが、チームの生産性に最も直接的なインパクトを与える「屋台骨」のメンテナンスです。
「とりあえず動く」状態から「なぜこの設定が必要で、どんな負荷を軽減しているのかを理解している」状態へ移行する。これこそが、一流のエンジニアへの第一歩です。
明日からのコーディングで、ぜひこの「戦略的除外」を取り入れてみてください。ツールがあなたを待たせるのではなく、あなたがツールを自在に操る、そんな快適な開発環境が待っています。