開発の「無駄な衝突」を撲滅せよ：ESLint v9 Flat Config時代の賢い住み分け術
こんにちは。現場の最前線でコードの品質と格闘しているエンジニアの皆さん。
開発の現場で、一度はこんな経験をしたことはないでしょうか？「ESLintがコードの書き方を注意してくるのに、Prettierがその修正を全力で打ち消して、無限ループのように差分が消えない」。
かつては `eslint-config-prettier` という救世主的なライブラリに頼り切っていましたが、ESLint v9の「Flat Config」導入を機に、その常識をアップデートする必要があります。今回は、依存関係に頼らず、ツールの役割を論理的に分離し、「設定ファイルがなぜこう書かれているのか」を完全に掌握するための、次世代のクリーンな構成術を伝授します。
—
1. なぜ「役割分担」が重要なのか
まず、ツールの役割を明確にしましょう。
- ESLintの役割は「コードの質（品質・ロジック）」：
変数の使い忘れ、セキュリティリスク、推奨されない構文など、「バグの温床」を見つけ出すのが仕事です。
- Prettierの役割は「コードの見た目（可読性）」：
インデント、改行、セミコロンの有無など、「人間が読みやすい形式」に統一するのが仕事です。
「フォーマット」は見た目の問題であり、コードの質ではありません。 ESLintにフォーマットの責任を持たせると、ツール同士が同じ場所（例えばセミコロンの有無）を奪い合い、競合が発生します。この重複を「設定を書き換えて無効化する」という対症療法ではなく、「そもそもESLintにフォーマットのルールを読み込ませない」という構造で解決するのが、今回のアーキテクチャの核心です。
—
2. 最小構成の構築：Flat Config（eslint.config.mjs）の真実
v9からは `eslint.config.mjs` が主役です。ここで重要なのは、「フォーマット系のプラグインをロードしない」という潔さです。
ステップ1：必要なパッケージのインストール
まずは必要最小限のパッケージを導入します。
ESLint本体と、TypeScriptの解析用パーサー
npm install –save-dev eslint @eslint/js typescript-eslint prettier
ステップ2：eslint.config.mjs の設計
ここで注目してください。`eslint-config-prettier` をインストールしていません。代わりに、「競合するルールを適用しない」という設計思想で構築します。
// eslint.config.mjs
import js from “@eslint/js”;
import tseslint from “typescript-eslint”;
export default tseslint.config(
// 1. ESLintが提供する推奨ルールを適用（ロジックの品質管理のみに集中）
js.configs.recommended,
…tseslint.configs.recommended,
{
// 2. ルールのカスタマイズ
rules: {
// ここに「見た目」に関するルール（semi, quotesなど）は一切書かない！
// これにより、Prettierとの衝突は物理的に発生しなくなる
“@typescript-eslint/no-unused-vars”: “warn”,
},
}
);
この設定の美しさは、「ESLintには品質に関することしか教えない」というルールを徹底している点にあります。これだけで、ツール間の泥沼の戦いは幕を閉じます。
—
3. Prettierの単独運用と自動化
PrettierはCLIツールとして独立させます。ESLint経由ではなく、直接Prettierを走らせるのが最も安全で高速です。
.prettierrc の設定
プロジェクトのルートに作成します。
{
“semi”: true,
“singleQuote”: true,
“tabWidth”: 2,
“printWidth”: 80
}
実行スクリプト（package.json）
開発効率を最大化するために、`scripts` を定義します。
{
“scripts”: {
// ESLintでロジックを確認
“lint”: “eslint .”,
// Prettierでフォーマットを修正
“format”: “prettier –write .”
}
}
—
4. なぜこれが最強の「HelloWorld」なのか
実際に試してみましょう。
1. わざと汚いコードを書く： `const x=10` （スペースが足りない、セミコロンがない）。
2. `npm run lint` を実行： ESLintは「`x` が使われていない」といったロジックの警告だけを出します。フォーマットについては一切文句を言いません。
3. `npm run format` を実行： Prettierが即座に `const x = 10;` と美しく整形します。
このワークフローを体験すると、「あぁ、今までいかに無駄な競合に悩まされていたか」と驚くはずです。
最後に：エンジニアとしての心得
今回紹介した方法は、ツールに依存するのではなく、「ツールの役割を理解し、設定を制御する」というエンジニアリングの基本に立ち返るものです。
依存関係を最小限に抑えることは、将来的なアップデート時のトラブルを激減させます。毎日のコーディングが、設定の微調整に追われる時間ではなく、本来の「創造的な実装」に集中できる時間になること。それこそが、この構成術の最大の恩恵です。
さあ、あなたのプロジェクトも今日から「競合のないクリーンな開発」を始めてみませんか？