ESLint Flat Configの深淵：継承の呪縛を解き、静的解析を「静かなる戦力」に変える設計術
かつてのESLintは、`.eslintrc`という名の「迷宮」でした。`extends`が連鎖し、どこで誰がルールを上書きしたのか追跡不能になるあの悪夢。しかし、ESLint v9で標準となったFlat Config (`eslint.config.js`) は、そのパラダイムを「配列による明示的な解決」へと変貌させました。
本稿では、単なる導入手順ではなく、大規模開発で破綻しない「意志ある設定」の構築方法を伝授します。
—
1. Flat Configの設計思想：なぜ「配列」なのか
Flat Configの本質は、「設定オブジェクトの配列」による順序依存の解決にあります。以前のESLintが再帰的でブラックボックスだったのに対し、Flat Configは上から下へ流れる「線形処理」です。
継承とオーバーライドの鉄則
Flat Configでは、配列のインデックスが後のものほど優先されます。
// eslint.config.js
import js from “@eslint/js”;
import ts from “@typescript-eslint/eslint-plugin”;
export default [
// 1. ベース設定：全ファイルに適用される広域的なルール
js.configs.recommended,
// 2. 特殊設定：特定のパターンにのみ適用
{
files: [“/.ts”], // TypeScriptファイルに限定
rules: {
“@typescript-eslint/no-explicit-any”: “error” // 厳格化
}
},
// 3. 上書き（最優先）：特定のディレクトリだけルールを緩める（例：テストコード）
{
files: [“/__tests__/“],
rules: {
“@typescript-eslint/no-explicit-any”: “off” // テストでは柔軟に
}
}
];
ここが重要： `files`を指定しないオブジェクトは「すべてのファイル」に適用されます。重要なのは、「広い範囲」から「狭い範囲」へ順に記述するという明確なレイヤー構造を意識することです。
—
2. 実務で「競合」を殺す：ignoreとスコープの罠
多くのエンジニアが陥る罠が、`ignores`プロパティのスコープです。Flat Configでは、`ignores`を空のオブジェクトとして定義すると、その階層以降の全ファイルを対象から外してしまいます。
ベストプラクティス：静的解析の「聖域」を守る
`ignores`は、設定配列の「先頭」または「独立した設定」で定義し、プロジェクト全体のパフォーマンスを担保しましょう。
export default [
// プロジェクト全体で無視するファイル
{
ignores: [
“dist/”,
“node_modules/”,
“coverage/”,
“/__snapshots__/” // スナップショットは解析対象外にするのが定石
]
},
// 以下、本番設定が続く…
];
—
3. 開発効率を極限まで高める「神プラグイン」と設定術
生産性を上げるには、ツールを「自動化」ではなく「学習の補助」として使うべきです。
絶対に入れるべきプラグイン：`eslint-plugin-import-x`
ESLintの標準機能だけでは解決できない「複雑な依存関係」を整理します。特に`import-x`（旧`eslint-plugin-import`のFlat Config対応版）は、巨大なプロジェクトでの循環参照を検出し、コードのモジュール化を強制的に促します。
開発体験(DX)を向上させるキーボードショートカット
IDE（VS Code）の設定で、以下のコードを`keybindings.json`に仕込んでください。
// 編集中のファイルを即座にLint修正し、保存する
{
“key”: “cmd+shift+s”,
“command”: “editor.action.formatDocument”,
“when”: “editorHasDocumentFormattingProvider && editorTextFocus”
}
—
4. チーム開発で「設定の崩壊」を防ぐ共有化ルール
チーム開発における最大の敵は、「メンバー間でのLintルールの揺れ」です。これを防ぐには、「共有設定のパッケージ化」を推奨します。
設定の共有化アーキテクチャ
プロジェクト直下に`eslint.config.js`を直接書くのではなく、`@company/eslint-config`のようなnpmパッケージを作成し、それを`import`する方式をとります。
// プロジェクト内のeslint.config.js
import { myCompanyConfig } from “@company/eslint-config”;
export default [
…myCompanyConfig,
{
rules: {
// そのプロジェクト固有のルールのみを記述
“no-console”: “warn”
}
}
];
なぜこれが必要か？ チームが複数に分かれた際、設定ファイルをコピペすると修正が伝播しません。npmパッケージ化することで、`npm update`するだけで全プロジェクトの静的解析レベルを最新に同期できるからです。
—
結論：コード品質は「自動化された意志」である
静的解析ツールは、単なる「エラーチェッカー」ではありません。「チームがどのような品質のコードを良しとするか」という合意形成の証（あかし）です。
Flat Configを理解し、設定を論理的に分離・階層化することは、技術的負債を未然に防ぐ最強の防御策です。
明日からできること：
1. 現在の`eslint.config.js`を「広い範囲」から「狭い範囲」へ並べ替える。
2. `ignores`を配列の先頭に集約し、不要な計算コストを排除する。
3. チーム固有のルールをnpmパッケージとして切り出し、メンテナンスコストを中央集権化する。
このレベルの設計を実践すれば、あなたのプロジェクトのコードは、誰が書いても一貫性のある「美しい資産」へと進化するはずです。現場のコードで震えるような体験を、ぜひその手で作り上げてください。