ESLintの「なぜか動かない」を1秒で解決する。`–print-config`でルール解決の迷宮を脱出せよ
こんにちは。開発環境アーキテクトです。
JavaScript/TypeScript開発において、ESLintとPrettierの導入は「必須」ですが、同時に「最も開発者の頭を悩ませるブラックボックス」でもあります。
「`.eslintrc.js`に設定を書いたのに、なぜかルールが効かない」「プラグイン同士が競合している気がするが、どこで上書きされているか不明」……そんな経験はありませんか？
今回は、そんなESLintのブラックボックスを破壊し、内部で何が起きているのかを可視化する「魔法のコマンド」を紹介します。これをマスターすれば、設定ファイルとの無駄な格闘から解放され、コーディングに集中できる時間が劇的に増えますよ。
—
1. なぜ「設定の迷宮」に陥るのか？
ESLintは強力ですが、その設定は「継承（extends）」「プラグイン（plugins）」「オーバーライド（overrides）」が複雑に重なり合う、いわば多層構造のレイヤーケーキです。
- extends: 外部の巨大な設定を読み込む。
- plugins: 新しいルールセットを追加する。
- overrides: 特定のファイルタイプ（例: `.test.ts`）に対して設定を上書きする。
この「最終的にどの設定が勝ったのか？」という解決プロセスは、脳内で計算するには限界があります。そこで登場するのが、ESLint公式が提供する隠し玉、`–print-config`です。
—
2. 魔法のコマンド `–print-config` の威力
`–print-config`は、「すべての継承と上書きが解決された後の、完全な最終設定ファイル」を標準出力に書き出すコマンドです。
実際に叩いてみよう
以下のコマンドをターミナルで実行してみてください。
特定のファイル（例: index.ts）に適用される最終ルールをJSON形式で出力
npx eslint –print-config src/index.ts > resolved-config.json
このコマンドが何をしているかというと、ESLintのエンジンが読み込むべき全設定をマージし、その結果生成された「最終的なオブジェクト」をJSONとしてダンプしているのです。
なぜこれが「現場で震えるほど役立つ」のか？
「このファイルに対して、具体的に今どのルールが有効なのか？」を知ることは、デバッグの最終兵器です。
- 優先順位の確認: どのプラグインが優先的に評価されたのかが一目瞭然になります。
- 不要なルールの特定: `extends`で読み込んだはずの設定が、実は別のルールで無効化されていた、といったミスに即座に気づけます。
- CI/CDでの検証: ローカルとCIで挙動が違う場合、このJSONを比較することで、環境依存の差異を科学的に特定できます。
—
3. ステップバイステップ：ESLintの「真実」を確認する手順
手順①：現在の設定を可視化する
まずは、問題の起きているファイルに対して先ほどのコマンドを実行し、ファイルを生成します。
手順②：`rules`セクションを検索する
生成された`resolved-config.json`を開き、`”rules”: { … }` を探してください。ここには、現在そのファイルに対して「有効」なルール設定がすべて記載されています。
{
“rules”: {
“no-console”: [“error”], // 最終的に有効になったルール
“semi”: [“error”, “always”], // Prettierと競合していないか確認可能
// …膨大なルールセット
}
}
手順③：疑わしい箇所を診断する
もし「`no-console`を許可したはずなのにエラーが出る」なら、このJSONの`no-console`部分を確認してください。もしここが `[“error”]` になっていれば、どこかで上書き（オーバーライド）が発生している証拠です。
—
4. 基礎セットアップ：最短で最高の結果を得るために
初心者がハマりがちなのが、ESLintとPrettierの競合です。これらを論理的に共存させるための「黄金のセットアップ」を共有します。
必要なパッケージのインストール
`eslint-config-prettier` を使うのが現代の標準です。これは「Prettierと衝突するESLintルールをすべて無効化する」ためのツールです。
npm install –save-dev eslint prettier eslint-config-prettier
`.eslintrc.json` の書き方（これが最善）
`extends`の最後に必ず`prettier`を置く。これが鉄則です。
{
“extends”: [
“eslint:recommended”,
“plugin:@typescript-eslint/recommended”,
“prettier” // 必ず最後！これが他の設定によるルールを強制終了させる
]
}
—
5. 最後に：アーキテクトからのアドバイス
ESLintのデバッグは、魔法ではありません。「最終的に生成されたデータを見る」という、極めてエンジニアリング的なアプローチが最短距離です。
もし設定で行き詰まったら、焦らずに `–print-config` を叩いてください。そこには、あなたが設定した通りの、正直なESLintの姿が映し出されています。
この「可視化する習慣」を身につければ、どんなに複雑なプロジェクトであっても、設定の迷宮に迷い込むことは二度となくなります。さあ、今すぐあなたのプロジェクトで `eslint –print-config` を実行し、その深淵を覗いてみてください。
あなたの開発体験が、今日からさらに快適なものになることを確信しています！