ESLintの「逃げ道」を塞げ：`eslint-disable`禁止がもたらす極限のコード品質とアーキテクチャの真実
多くのプロジェクトで目にする光景がある。複雑なロジックを前にして、あるいは期限に追われて、エンジニアが「魔法の呪文」を唱える瞬間だ。
`// eslint-disable-next-line`
この一行は、開発のスピードを一時的に加速させるかもしれない。しかし、それは「技術的負債という名の時限爆弾」をコードベースの深層に埋め込む行為に他ならない。本稿では、この悪習をシステム的に根絶し、真にメンテナンス可能なコードベースを構築するための、アーキテクト視点での実践戦略を伝授する。
—
1. なぜ `eslint-disable` を全廃すべきなのか
`eslint-disable` が多用されるチームには、以下の「負のサイクル」が定着している。
1. ルールの形骸化: 「守れないなら消せばいい」という意識が、静的解析の価値をゼロにする。
2. 文脈の消失: なぜそのルールを無視したのかという意図がコメントに残らず、後続のエンジニアは「このコードを直していいのか？」と迷うコストが発生する。
3. カオスな依存関係: ルールを無視した箇所が、将来的なリファクタリングの最大の障害となる。
私たちは、「ルールを無視する」のではなく、「ルールそのものを進化させる」文化を醸成しなければならない。
—
2. 禁断の果実を封印する：`eslint-plugin-eslint-comments` の導入
「禁止」を口頭で伝えても無駄だ。システムで強制せよ。我々が導入するのは、ESLintコメント自体を制御するプラグインである。
推奨設定: `.eslintrc.json`
{
“plugins”: [“eslint-comments”],
“rules”: {
// そもそもeslint-disable系コメントを全禁止する
// ただし、どうしても必要なケースがある場合は「理由の記述」を強制する
“eslint-comments/no-use”: [“error”, { “allow”: [] }],
// eslint-disable系のコメントを記述する際は、必ず説明（–）を必須とする
// これにより、将来のエンジニアに対する意思表示を強制する
“eslint-comments/require-description”: [“error”, { “ignore”: [] }]
}
}
この設定により、`// eslint-disable-next-line` と書くだけではエラーとなり、`// eslint-disable-next-line — なぜこのルールを無効化するのかという必然性をここに記述せよ` と書かなければコミットすら許されない状態を作る。
—
3. 「神プラグイン」と「IDEショートカット」による生産性の極致
ルールを厳格化すると、当然ながら修正の頻度が増える。これを「苦痛」ではなく「コード改善の機会」に変えるのが、プロの技だ。
推奨プラグイン
- [ESLint (VS Code拡張)](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint): 言わずもがな。`eslint.probe` 設定で、TS/JS以外にも対象を広げることが重要。
- [Error Lens](https://marketplace.visualstudio.com/items?itemName=usernamehw.errorlens): これが本稿の肝だ。 Lintエラーをエディタ上にインラインで表示する。エラーログを探してターミナルを往復する時間はゼロになる。即座に「なぜルール違反なのか」を理解し、修正できる。
隠れたキーボードショートカット (VS Code)
- `Cmd + .` (Quick Fix): エラー箇所でこれを叩く。ESLintの修正提案を即座に適用する。これなしでLint作業を行うのは、裸足で山を登るようなものだ。
—
4. プロの運用ガイドライン：ルールの進化
「ルールが厳しすぎて開発が進まない」という声が上がったら、それは「そのルールが現在のプロジェクトのフェーズに適していない」というシグナルだ。
ルール改善のためのプルリクエスト・フロー
1. ルールの緩和を提案する: チーム内で「このルールは現在のアーキテクチャでは非効率的だ」と合意を得る。
2. ルール定義の変更: `.eslintrc.json` を更新する。
3. 自動修正の実行: `eslint –fix` を全コードベースに対して実行する。
これにより、プロジェクト全体が「最新の基準」へとアップデートされる。「特定の箇所だけ黙認する」のではなく「プロジェクト全体でルールをアップデートする」。これが技術的負債を累積させない唯一の道だ。
—
5. アーキテクトからの提言：CI/CDとの統合
ローカルでのLintはあくまで「予防」に過ぎない。CI/CDパイプラインにおいて、以下の設定を必ず含めること。
GitHub Actionsの例
- name: Lint
run: |
# 警告も全てエラーとして扱い、パイプラインを止める
# これにより「警告だから放置」という甘えを排除する
npm run lint — –max-warnings 0
`–max-warnings 0` を付与することで、警告すら許さない強固なゲートキーパーを構築する。これが、大規模開発においてコードの腐敗を防ぐ最後の防衛線となる。
—
結論
`eslint-disable` を禁じることは、単なるルール作りではない。それは、「自分たちのコードに責任を持ち、常に最適解を模索し続ける」というプロフェッショナリズムの表明だ。
コードは書かれた瞬間から劣化が始まる。その劣化の速度を極限まで落とすことこそが、私たちエンジニアが提供できる最大の価値である。今すぐプロジェクトから「逃げ道」を排除せよ。そこから、真の生産性とコードの美しさが始まる。