泥沼の「フォーマット不一致」を根絶せよ：Prettier & ESLintの深淵とCI/CDによる完全統治
「保存時にPrettierが動かない」「ローカルとCIでLintエラーが食い違う」。この種のトラブルは、開発現場における生産性の癌であり、エンジニアの精神衛生を最も削る要素だ。
本稿では、VSCodeの設定の深淵から、CI/CDパイプラインによる強制力まで、「フォーマットの不一致を物理的に不可能にする」ためのアーキテクチャ設計を解説する。これは単なる設定の羅列ではない。君たちのチームのコードベースに「唯一絶対の真実」を刻み込むための設計思想である。
—
1. VSCodeの「魔境」を物理的に封印する
VSCodeでPrettierが効かない原因の9割は、「拡張機能の競合」と「設定の優先順位の理解不足」にある。これを解決するには、プロジェクトルートの `.vscode/settings.json` を通じて、ワークスペース設定を強制的に上書きするのが鉄則だ。
`.vscode/settings.json` による強制介入
以下の設定は、エディタの挙動をプロジェクトのルールに物理的に従属させるための「絶対命令」である。
{
// デフォルトのフォーマッタをPrettierに固定
“editor.defaultFormatter”: “esbenp.prettier-vscode”,
// 保存時の自動整形を有効化（これが効かない場合、拡張機能が干渉している）
“editor.formatOnSave”: true,
// 言語ごとの細かな設定を無効化し、Prettierに一任する
“[javascript][typescript][typescriptreact]”: {
“editor.defaultFormatter”: “esbenp.prettier-vscode”,
“editor.codeActionsOnSave”: {
// ESLintの自動修正を保存時に走らせる（重要：Prettierの後に実行される）
“source.fixAll.eslint”: “explicit”
}
},
// ファイル末尾の改行を強制（Gitの差分爆弾を防ぐ）
“files.insertFinalNewline”: true
}
なぜ「拡張機能の優先順位」で事故るのか？
VSCodeの拡張機能はインストール順や無効化状態によって読み込み順が変わる。`eslint-plugin-prettier` を使っている諸君、今すぐ捨てろ。
現在のモダンな設計では、`eslint-config-prettier` を使用し、ESLintは「コードの品質（論理）」、Prettierは「コードの見た目（物理）」と責務を完全に分離すべきだ。これにより、競合を物理的に消滅させることができる。
—
2. CI/CDパイプラインを「検閲機関」に変貌させる
ローカルの自動整形を信じるな。「フォーマットされていないコードはコミットできない」という制約を物理的に課せ。
Husky + lint-staged による防波堤
コミット時に `lint-staged` を動かすのは基本だが、さらに一歩進んで「Prettierのチェックが通らないコードはマージさせない」というポリシーをCIに組み込む。
.lintstagedrc.json の設計例
{
“.{js,ts,tsx}”: [
“prettier –write”, # フォーマットを強制修正
“eslint –fix” # 静的解析で修正可能なものを修正
]
}
GitHub Actions による「容赦なきチェック」
CI上では `–check` フラグを使用する。これは修正するのではなく「失敗させる」ためのモードだ。
.github/workflows/lint.yml
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with: { node-version: ’20’ }
- run: npm ci
# フォーマットが崩れていればCIは即座に落ちる
- run: npx prettier –check .
# 構文上の不備があればCIは即座に落ちる
- run: npx eslint .
—
3. 実行効率の極限：アーキテクトのための最適化ハック
大規模プロジェクトにおいて、`prettier –write .` は数万ファイルを舐めるため、CIのボトルネックになり得る。
1. 差分検知の最適化
CI環境下では、全ファイル走査は非効率だ。`git diff` を活用し、変更があったファイルのみをターゲットにするスクリプトをCIの入口に配置せよ。
変更されたファイルだけを抽出してPrettierを叩く
CHANGED_FILES=$(git diff –name-only origin/main…HEAD –diff-filter=d | grep -E ‘\.(js|ts|tsx)$’)
if [ -n “$CHANGED_FILES” ]; then
npx prettier –check $CHANGED_FILES
fi
2. Dockerコンテナでの完全自動構成
開発環境の差異をゼロにするために、VSCodeの「Dev Containers」を使え。`.devcontainer/devcontainer.json` に上記の設定をすべて記述し、チーム全員が全く同じ環境で開発するように仕向ける。これにより、「私のPCでは動く」という言い訳を物理的に排除する。
—
結びに：ツールを飼い慣らすということ
自動整形ツールの設定は、単なる「おまじない」ではない。それはチームのエンジニアが「コードの品質や設計といった本質的な作業に脳のリソースを全振りできるようにするためのインフラ整備」だ。
Prettierが効かないと悩む時間は、エンジニアのキャリアにおいて最も生産性の低い時間である。今回示したアーキテクチャを導入し、フォーマットに関する議論をチームから完全に消し去り、その余剰エネルギーを技術的負債の返済や新機能の開発に回してほしい。
これこそが、ツールを真に掌握したエンジニアの戦い方である。