脱・設定の迷宮：ESLint v9 “Flat Config” 時代の Prettier 連携と、真にモダンなコード品質管理術
多くのチームが「ESLint と Prettier の競合問題」という泥沼に足を取られています。`eslint-config-prettier` をインストールし、`extends` の末尾に記述して祈る……そんな時代はもう終わりました。
ESLint v9（Flat Config）の登場は、単なる設定ファイルの変更ではありません。これは「ツールを重ねる」という負債から脱却し、「役割を分離する」というアーキテクチャの転換を意味します。本稿では、依存関係を極限まで削ぎ落とし、CIの実行速度と開発者の認知負荷を最小化する「真のモダン設定」を伝授します。
—
1. なぜ「設定の重ね塗り」は技術的負債となるのか
従来の ESLint 設定（`.eslintrc`）は、プラグインを読み込めば読み込むほど、ルールがカスケードされ、どのプラグインがどのルールを上書きしているのか判別不能な「ブラックボックス」と化していました。
Flat Config（`eslint.config.js`）の哲学は明確です。「ESLint はコードの構造と論理的なエラーを監視し、Prettier は文字列のレイアウトだけを担当する」。この境界線を曖昧にせず、設定ファイル側で強制的に切り離すのが、現代のテックリードが行うべき責務です。
—
2. 【実践】依存関係に頼らない「最小構成」の構築
`eslint-config-prettier` をインストールして満足していませんか？ 実は、Flat Config においては、特定のプラグインがルールを競合させるケースは極めて限定的です。まずは、`eslint-config-prettier` を捨て、明示的な「ルール無効化」を行うことで、依存ツリーをクリーンに保ちます。
`eslint.config.js` の設計思想
import js from “@eslint/js”;
import prettierRecommended from “eslint-plugin-prettier/recommended”;
export default [
// 1. ESLint 標準の推奨ルールを適用
js.configs.recommended,
// 2. Prettier 関連の競合するルールを無効化する最もクリーンな手法
// eslint-plugin-prettier/recommended を使うことで、
// 競合するルールを自動的にオフにし、Prettier を ESLint のルールとして実行する
prettierRecommended,
{
// 3. ここでプロジェクト固有のルールを定義
// ここには「フォーマット」に関するルールは一切書かないこと
rules: {
“no-console”: “warn”,
“prefer-const”: “error”,
// 「セミコロンをつけるか否か」といった議論はPrettierに全投げする
}
}
];
なぜこれが最強なのか？
この構成であれば、ESLint は「コードの品質」のみを評価し、Prettier は「コードの整形」のみを制御します。ESLint のルールセットがどれだけ巨大になっても、Prettier 側の設定が汚染されることはありません。
—
3. 開発スピードを極限まで加速させる「神テクニック」
VS Code 設定の「完全自動化」
開発者の手をわずらわせる「保存時の挙動」は、`settings.json` で完全に統一します。チーム全員が同じ挙動を強制される環境こそが、コンテキストスイッチを最小化します。
{
// 保存時に ESLint で自動修正を行い、Prettier で整形する
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit”
},
// ファイルタイプごとのデフォルトフォーマッタ指定
“[javascript][typescript][typescriptreact]”: {
“editor.defaultFormatter”: “esbenp.prettier-vscode”,
“editor.formatOnSave”: true
}
}
隠れたキーボードショートカット：`F8` を制する
ESLint のエラーをわざわざマウスでホバーしていませんか？
- `F8` / `Shift + F8`: 次のエラー / 前のエラーへジャンプ。
- `Cmd + .` (Mac) / `Ctrl + .`: クイックフィックスの呼び出し。
この2つを体に染み込ませるだけで、コーディング中の修正速度は2倍になります。
—
4. チーム開発における「品質の防波堤」：CIの最適化
大規模プロジェクトにおいて、毎回全ファイルをLintするのは時間の浪費です。差分だけをLintし、高速なCI環境を構築しましょう。
`package.json` のベストプラクティス
`lint-staged` を活用し、Git のステージング領域のみをターゲットにします。
{
“lint-staged”: {
“.{js,ts,tsx}”: [
“eslint –fix”, // ロジックの修正を先に適用
“prettier –write” // 最後にフォーマットを適用
]
}
}
アーキテクトの視点:
この順序が重要です。`eslint –fix` でコードの論理的な修正を行い、その結果生じた微妙な空白や改行の乱れを、最後に `prettier` が修正する。このパイプラインを維持することで、フォーマット不備によるコミット履歴の汚染を100%防ぐことができます。
—
最後に：ツールを使いこなすのではなく「制約」を愛せ
コード品質管理において最も重要なのは、ツールを入れることではありません。「人間が判断しなくてもいいこと」をすべてマシンに委ねるという設計思想です。
今回紹介した構成は、複雑な依存関係を排除し、ESLint v9 のパワーを最大限に引き出すための最小単位です。まずは皆さんのプロジェクトの `package.json` から、不要な `eslint-config-xxxx` 系を1つ削除することから始めてみてください。その瞬間に、プロジェクトのビルド時間は短縮され、開発者の認知負荷は劇的に軽くなるはずです。
エンジニアの時間は、ルールの競合をデバッグするためにあるのではありません。プロダクトの価値を最大化するためにあるのです。