ESLint Flat Config (v9) 完全移行：単なる「形式変更」にあらず、ツールチェインの再定義
多くのチームが「なんとなく」設定ファイルをコピー＆ペーストで運用しているESLint。しかし、v9で導入されたFlat Configは、単なる設定ファイルのフォーマット変更ではありません。これは、「設定の継承という名の迷宮」からの脱却と、ESLintエンジンのモジュール化された現代的アーキテクチャへの昇華を意味します。
なぜ今、Flat Configへの移行が不可欠なのか。それは従来の`.eslintrc`が抱えていた「暗黙的なディレクトリ再帰検索」という非効率な設計が、大規模プロジェクトのパフォーマンスを劇的に悪化させていたからです。
—
1. なぜ「Flat Config」でなければならないのか：内部挙動の真実
従来の`.eslintrc`は、ファイルを開くたびに上位ディレクトリを探索し、設定を「マージ」して解決していました。これがCIの実行時間を延ばし、設定の競合（どの設定が優先されているのか誰にも分からない状態）を生む元凶でした。
Flat Configは、「設定は配列（Array）である」という極めてシンプルな原則に立ち返りました。この変更により、以下の利益がもたらされます。
- 明示的なスコープ制御: `files`プロパティによるファイル単位の厳密なルール適用。
- ゼロ・オーバーヘッド: 再帰的なファイル検索を廃止し、設定オブジェクトをシリアライズ可能な形で扱うことで、IDEの解析速度が向上。
- TypeScriptとの親和性: 型定義が効く`.js`ファイル（または`.ts`ファイル）として設定を記述できるため、補完が完全に機能する。
—
2. 移行プロセスの鉄則：段階的アプローチ
いきなり全てを書き換えるのではなく、まずは「互換性」を維持しつつ、エンジンをv9に載せ替えるのが定石です。
Step 1: 移行用パッケージの導入
旧設定を維持したままv9のエンジンを走らせるためのブリッジを導入します。
ESLint 9.0へのアップグレード
npm install eslint@latest –save-dev
旧設定をFlat Configとして読み込むためのブリッジ
npm install @eslint/eslintrc –save-dev
Step 2: `eslint.config.js` の構築
ここからが本番です。以下の構造は、プロフェッショナルな現場で採用すべき「分離・合成可能」なベストプラクティスです。
// eslint.config.js
import { FlatCompat } from ‘@eslint/eslintrc’;
import js from ‘@eslint/js’;
import typescriptEslint from ‘@typescript-eslint/eslint-plugin’;
import tsParser from ‘@typescript-eslint/parser’;
const compat = new FlatCompat();
export default [
// 1. 共有設定のベースラインを定義
js.configs.recommended,
// 2. 旧設定の資産を統合（移行期に必須）
…compat.extends(‘eslint:recommended’, ‘plugin:react/recommended’),
// 3. プロジェクト独自のルール定義（TypeScriptの型安全を担保）
{
files: [‘/.{ts,tsx}’],
languageOptions: {
parser: tsParser,
parserOptions: { project: ‘./tsconfig.json’ }
},
rules: {
‘@typescript-eslint/no-explicit-any’: ‘error’, // 型安全を死守する
‘no-console’: ‘warn’ // 本番環境への混入を防ぐための基本
}
},
// 4. 無視設定（Flat Configではここで行うのがルール）
{
ignores: [‘dist/’, ‘node_modules/’, ‘coverage/’]
}
];
—
3. 開発効率を「極限」まで引き上げる神ツールと設定
設定ファイルが整ったら、次は「開発体験」を最適化します。
推奨プラグイン：`eslint-plugin-perfectionist`
ESLintでimport文を自動整列させるプラグインです。これを導入すると、チームメンバー間での「コードの書き方」に関する不毛な議論が消滅します。
// 設定例: importのアルファベット順強制
rules: {
‘perfectionist/sort-imports’: [‘error’, { type: ‘alphabetical’ }]
}
隠れたキーボードショートカット（VS Code）
設定ファイルを変更した際、ESLintサーバーを再起動するためにコマンドパレットを開くのは時間の無駄です。
- `Ctrl + Shift + P` -> `ESLint: Restart ESLint Server` をキーバインド `Alt + R` に登録してください。これだけで、設定反映のサイクルが3秒早まります。
—
4. チーム開発における「絶対的ルール」
ツールは導入しただけでは陳腐化します。以下の規約をチームで共有してください。
1. 「ルールはコードで管理し、ドキュメントに頼らない」:
`eslint.config.js`はJSファイルです。複雑なルール分岐が発生した場合は、設定ファイルを分割して`import`してください。
2. Prettierとの明確な棲み分け:
ESLintのルールで「見た目」を制御するのは禁止です。`eslint-config-prettier`を使い、フォーマット系ルールをすべてオフにしてください。
- 思想: 「ESLintは論理的なバグを防ぐため、Prettierは誰が書いても同じ形にするため」。この役割分離を崩さないことが、CIの平和を保つ鍵です。
3. CIでの強制:
`eslint –max-warnings 0` をCIコマンドに含めてください。警告を放置するチームに品質向上は訪れません。
—
アーキテクトからのメッセージ
Flat Configへの移行は、単なるバージョンアップではありません。それは、あなたのプロジェクトが「技術的負債の集積地」から「疎結合でメンテナンス性の高いモジュール群」へと進化するための通過儀礼です。
設定ファイルの行数が増えることを恐れないでください。「何を禁止し、何を許可するか」がコードとして明示されていることこそが、最も強力なドキュメントなのです。
さあ、今すぐ `eslint.config.js` を作成し、その圧倒的な解析速度の向上を体感してください。あなたのチームが、より生産的で、より美しいコードを書けるようになることを確信しています。