こんにちは。開発環境の深淵へようこそ。
ESLintの「Flat Config（`eslint.config.js`）」への移行、皆さんはもう済ませましたか？
従来の `.eslintrc` に慣れ親しんだエンジニアほど、この新しい「フラットな世界」で設定の競合に頭を抱えることが多いようです。しかし、ここを制する者は、チーム開発の品質と速度を完全にコントロール下に置けます。
今日は、単なる書き方の説明ではなく、「なぜFlat Configが配列という形式を採用したのか」という設計思想の核心に触れつつ、現場で絶対にハマる「設定の競合」をスマートに解決する方法を解説します。
—
1. なぜ「Flat Config」が必要だったのか？
これまでの `.eslintrc` は、ディレクトリごとに設定が継承される「カスケード（滝）」構造でした。これは一見便利ですが、巨大なプロジェクトになると「結局どのルールが、どのファイルに適用されているのか」を特定するのが不可能に近い状態でした。
Flat Configの最大の革新は、「設定を単なるオブジェクトの配列として扱う」ことにあります。
- 配列のインデックスが「優先順位」そのもの
- 後ろにある設定ほど、前の設定を上書きする
これだけです。非常にシンプルですが、強力な設計思想です。
—
2. 実践：衝突を防ぐ「静的解析の要塞」を築く
ESLintとPrettierを共存させる際、最も多いトラブルが「ESLintがPrettierのフォーマットをエラーとして検知する」という不毛な争いです。これを解決する決定版の設定を見ていきましょう。
最小構成の `eslint.config.js`
import js from “@eslint/js”;
import prettierConfig from “eslint-config-prettier”; // Prettierとの競合を無効化するプラグイン
export default [
// 1. 基本設定：すべてのJSファイルに適用
js.configs.recommended,
// 2. プロジェクト固有の厳格なルール
{
rules: {
“no-unused-vars”: “warn”, // 未使用変数は警告レベルに
“prefer-const”: “error”, // 再代入不可な変数はconstを強制
}
},
// 3. Prettierの設定：最後に配置して全ての競合を打ち消す
// これを配列の最後に置くことで、他の全てのフォーマット系ルールを無効化します
prettierConfig,
// 4. 特定ファイルへのオーバーライド（これが重要！）
{
files: [“/.test.js”], // テストファイルにのみ適用
rules: {
“no-console”: “off”, // テスト中だけはconsole出力しても良い
}
}
];
なぜこの順番が最強なのか？
配列の先頭から順に評価されるため、「ルールを定義し、最後に競合するルールを無効化する」という順序が守られています。Prettierを配列の最後尾に配置することで、「ESLintがフォーマットに関与してくる」という事態を物理的に遮断できるのです。
—
3. 「ignore」のスコープを完全支配する
Flat Configの設計で多くの人が躓くのが `ignores` です。実は、Flat Configでは「設定オブジェクト」の中に書くか、トップレベルに書くかで挙動が変わります。
推奨：トップレベルでの一括管理
export default [
// これでプロジェクト全体から node_modules や dist を除外
{
ignores: [“dist/“, “node_modules/“, “coverage/”],
},
// 以降のルールは除外されたファイルには一切触れない
{
files: [“src//.js”],
rules: { / … / }
}
];
プロの視点：
`ignores` を設定オブジェクトの途中に配置すると、その前までの設定が無視され、予期せぬ混乱を招きます。`ignores` は常に配列の先頭付近に置くのが、環境アーキテクトとしての定石です。
—
4. 動作確認：HelloWorldならぬ「Lint確認」
設定が正しく効いているか確認するには、わざとエラーを出すのが一番の近道です。
プロジェクトルートで以下を実行
npx eslint src/index.js
もし設定が衝突していれば、eslintは同じルールに対して複数の警告を出します。何も出なければ、あなたの設定は堅牢です。
—
最後に：なぜこの知識が「現場で震えるほど」役立つのか
新人エンジニアは、よく「動かないから」という理由で、ネットから拾ってきた設定を継承元も理解せずに追加し続けます。すると、`eslint.config.js` は数千行のゴミ溜めと化し、CI/CDで謎のエラーを吐き出し始めます。
今回紹介した「配列の順序を意識する」「最後に特化ルールを置く」「ignoresを分離する」という3つの原則をマスターすれば、あなたはチームの中で「設定の不具合を即座に特定できる頼れる存在」になれます。
環境設定は、単なる作業ではありません。「コードが守られるべき境界線を引く」という重要な設計行為です。自信を持って、あなたのコードベースを美しく保ってください。
また次回の深い知見でお会いしましょう。ハッピーコーディング！