現場で震えるほど役立つ知見：Prettier `overrides` がもたらす「妥協なきコード品質」の真髄
多くのエンジニアが「Prettierの設定？`.prettierrc`をルートに置けば終わりだ」と勘違いしている。しかし、大規模なモダンフロントエンド、あるいはBFF（Backend For Frontend）としてNode.jsが同居する複雑なモノレポにおいて、その設計は「技術的負債の種」に他ならない。
なぜなら、プロジェクトの成長とともに、一律のルールは必ず「表現力の限界」を迎えるからだ。
本稿では、単なる設定の羅列ではなく、Prettierの `overrides` 機能と、それをCI/CDおよびDocker環境で極限まで最適化するための「アーキテクト視点のハック」を伝授する。
—
1. `overrides` が解決する本質的課題
なぜわざわざ `overrides` を使うのか。それは、言語やコンテキストによって「読みやすさ」の正義が異なるからだ。
例えば、ReactのJSXでは「タグ内のアトリビュートを縦に並べる」のが可読性の要だが、シンプルなJSONやMarkdownの設定ファイルでは「コンパクトに収める」ほうが視認性が高い。これを一律のルールで縛ると、どちらかが必ず犠牲になる。
{
“semi”: false,
“singleQuote”: true,
“overrides”: [
{
“files”: “.json”,
“options”: {
“tabWidth”: 2, // JSONはネストが深くなりがちなのでインデントは2に固定
“trailingComma”: “none”
}
},
{
“files”: [“.md”, “.mdx”],
“options”: {
“proseWrap”: “always”, // 日本語Markdownの改行位置を固定し、差分を極小化する
“printWidth”: 80
}
}
]
}
アーキテクトの洞察: `proseWrap: “always”` は単なる好みではない。Gitでの差分管理において、長い一行のMarkdownは「どの段落が変更されたか」を追跡不可能にする。これを強制することで、プルリクエストの可読性は劇的に向上する。
—
2. コンテナ環境での「完全自動構成」とパフォーマンスハック
大規模プロジェクトにおいて、ローカル環境とCI環境でのPrettierのバージョン差異や、OS起因の改行コード（CRLF/LF）問題は、開発体験を著しく損なう。
これを排除するため、Dockerコンテナ内で `prettier –write` を走らせる際、メモリ割り当てとスキャン範囲の最適化が必須となる。
Dockerfileでの最適化戦略
`node_modules` やビルド成果物を含めた全スキャンは、大規模プロジェクトではCIの時間を数分単位で浪費する。`–ignore-path` の活用だけでなく、コンテナ起動時に最適化されたCLIを実行せよ。
CI環境での実行コマンド例
–cache: 前回のフォーマット結果を保持し、変更差分のみを再計算する（必須）
–loglevel warn: 大量ログによるI/Oボトルネックを回避
–write: 書き込み処理を並列化させるプロセス管理
npx prettier –write . \
–cache \
–cache-strategy content \
–ignore-path .prettierignore \
–loglevel warn
ハック: `–cache-strategy content` を指定することで、ファイル名の変更やタイムスタンプの揺らぎに左右されず、コンテンツのハッシュ値で判定を行う。これにより、CIの実行時間を80%以上削減できるケースが多い。
—
3. CI/CDパイプラインとの高度な連携
PrettierをCIに組み込む際、単に「失敗したら落とす」だけでは三流だ。最高峰の現場では、「自動修正コミットの自動プッシュ」までをパイプラインで完結させる。
GitHub Actionsによる自動フィックスの例
開発者がフォーマット忘れをした際、CIが修正してコミットを押し戻す仕組みを構築する。
- name: Prettier Check & Fix
run: |
# 修正が必要なファイルのみを抽出し、修正を適用
npx prettier –write .
# 差分があるか確認
if [ -n “$(git status –porcelain)” ]; then
git config user.name “github-actions[bot]”
git config user.email “github-actions[bot]@users.noreply.github.com”
git add .
git commit -m “chore: auto-format with prettier”
git push
fi
注意: この手法は、エンジニアのローカルのコミットログを汚す可能性がある。これを嫌うチームの場合は、`–check` フラグを用いて「CIを落とし、修正方法をPRのコメントで通知する」というアプローチを推奨する。
—
4. 内部アーキテクチャから紐解く「最適化の極致」
Prettierの内部は、AST（抽象構文木）を生成し、それを再構成する非常に高コストな処理を行っている。ファイル数が数千を超える場合、`prettier` の実行はCPUとメモリを激しく消費する。
現場での解決策:
1. ステージングされたファイルのみを対象にする: `lint-staged` を使い、コミット直前のファイルのみをフォーマット対象とする。これは「全ファイルスキャン」という設計思想そのものを捨てる行為であり、最もスケーラブルな解だ。
2. ワーカープロセスの制御: 大規模な `overrides` を多用すると、設定のパースコストが累積する。設定ファイルは複雑化しすぎず、共有ルールを `base-config` として分離し、extends的に読み込む設計を心がけよ。
—
結び：アーキテクトからの提言
Prettierは単なる「コードを綺麗にするツール」ではない。それは、「チームがコードのスタイルについて議論するコストをゼロにするための、強力な政治的合意形成ツール」である。
`overrides` を使いこなすことは、個々の言語特性を尊重しつつ、プロジェクト全体で一貫した「品質基準のOS」を構築することと同義だ。技術の細部にまで拘泥し、自動化のパイプラインを極限まで磨き上げろ。それが、エンジニアリングの生産性を最大化するための、唯一にして最短の道である。