ESLintは「ブラックボックス」ではない：`–print-config`でルール解決の真実を暴く
開発現場で最も時間を浪費するのは、コードが「なぜか怒られる」「なぜか無視される」という謎のLintエラーと格闘する時間です。特に、`extends`で多重継承された設定や、プロジェクトルートから深い階層まで散らばる `.eslintrc`、あるいは `overrides` の複雑な条件分岐が組み合わさると、人間の脳内で「最終的にどのルールが優先されているか」を追跡するのは不可能です。
多くのエンジニアは、エラーが出るたびに手探りで設定を書き換えます。しかし、真のプロフェッショナルは、ESLintという静的解析エンジンが、最終的にどのような「解決済み設定（Resolved Config）」を保持しているかを直視します。
それが `eslint –print-config
1. なぜ `–print-config` が「神ツール」なのか
このコマンドは、単なる設定表示ではありません。ESLintが内部的に行う「階層的な設定のマージ」「プラグインの読み込み」「ルールの優先順位付け」という複雑な解決プロセスを完了させた後の、「生のJSON」を出力するデバッグの特効薬です。
特定のファイルに適用される最終的なルール設定をJSONで書き出し、確認する
npx eslint –print-config src/components/Header.tsx > resolved-config.json
このコマンドを叩いた瞬間に現れる数千行のJSONこそ、あなたのコードを縛っている「真のルールセット」です。
診断のステップバイステップ：予期せぬ挙動を叩き潰す
1. 特定ファイルの挙動に違和感がある場合: そのファイルパスを指定して `–print-config` を実行します。
2. `rules` セクションを検索: 疑わしいルール名（例: `@typescript-eslint/no-explicit-any`）で検索します。
3. `rules` の値を確認:
- `”off”` や `0` になっているか？
- `”error”` や `2` になっているか？
- 重要： `plugins` のリストに該当するプラグインが含まれているか？
もし `rules` に設定があるのに期待通り動かない場合、十中八九 `plugins` の読み込み漏れか、`extends` の順序ミスによる上書きが発生しています。このコマンドを使えば、「設定したはずなのに！」という絶望とは今日で決別できます。
—
2. 開発体験を劇的に変える「隠れたテクニック」
VS Codeの「出力ログ」でESLintの思考を覗き見る
コマンドラインだけでなく、IDE側でもESLintの「思考」を可視化できます。VS Codeのコマンドパレットから `ESLint: Show Output Channel` を選択し、出力を `Verbose` に設定してください。
すると、ESLintが「どの設定ファイルを読み込み、どのキャッシュを無効化し、どのルールを適用しようとしているか」がリアルタイムでログとして流れます。Lintが極端に遅い場合、このログを見れば「特定の巨大なファイルが解析コストを食いつぶしている」といったボトルネックが一瞬で特定できます。
開発を加速させる「神プラグイン」の選定基準
「とりあえず人気だから」でプラグインを入れるのは厳禁です。以下の2つは、モダンなTSプロジェクトであれば必須の「生産性向上エンジン」です。
- `eslint-plugin-import`: 依存関係の循環参照や、存在しないパスへのインポートを静的に弾きます。特に大規模プロジェクトでは必須。
- `eslint-plugin-perfectionist`: インポート文やオブジェクトのキー、型定義のアルファベット順ソートを自動化します。これだけで「コードの整理」にかかる脳のリソースをゼロにできます。
—
3. チーム開発における「メンテナンス不能」を防ぐベストプラクティス
設定ファイルが肥大化し、「誰も触れない聖域」になるのを防ぐためには、「継承の階層化」が鍵です。
推奨される構成例 (`.eslintrc.js`)
module.exports = {
root: true, // これを忘れると親ディレクトリの設定を拾いに行き、予期せぬバグを招く
env: { browser: true, es2021: true, node: true },
extends: [
‘eslint:recommended’,
‘plugin:@typescript-eslint/recommended’,
‘prettier’ // Prettierは常に最後に配置し、Lintと競合するルールを無効化させる
],
parser: ‘@typescript-eslint/parser’,
plugins: [‘@typescript-eslint’, ‘import’],
rules: {
// プロジェクト全体で守るべき「厳格なルール」のみを記述
‘@typescript-eslint/no-unused-vars’: [‘error’, { argsIgnorePattern: ‘^_’ }],
},
// ファイルタイプごとに設定を分離し、可読性を維持する
overrides: [
{
files: [‘/.test.{ts,tsx}’],
rules: {
‘@typescript-eslint/no-explicit-any’: ‘off’, // テスト時は柔軟性を許容
}
}
]
};
最後に：テックリードからの提言
ESLintとPrettierを「コードを綺麗にするツール」だと思っていませんか？ それは大きな勘違いです。これらは「チーム開発における暗黙知を明文化し、人間がコードレビューという高次元の創造的な作業に集中するためのインフラ」です。
`–print-config` を使いこなすということは、あなたのプロジェクトの「ルール」を完全に掌握し、制御下におくことを意味します。ツールに振り回されるのではなく、ツールをエンジニアリングの延長として使いこなしてください。
今日、プロジェクトのルートでコマンドを叩き、自分のコードがどのような「ルール」という名の憲法によって守られているのか（あるいは縛られているのか）、その目で確認してみてください。そこから、真の生産性向上は始まります。