「なぜ、あなたのコードは汚れるのか？」ESLintの禁断症状を根治するアーキテクチャ設計
こんにちは。世界中のプロダクトのコードベースを渡り歩いてきた私から、一つだけ皆さんに問いかけたいことがあります。
「なぜ、あなたは `// eslint-disable-next-line` を書くのですか？」
多くの現場で、このコメントは「困った時の魔法の杖」として乱用されています。しかし、アーキテクトの視点から言わせれば、それは「技術的負債という名のゴミを、カーペットの下に隠している」のと同じ行為です。
今日は、初心者の方が陥りがちな「とりあえず無効化」という罠を断ち切り、「ルールを破るのではなく、ルールを育てる」という、プロフェッショナルな開発の流儀を授けます。
—
1. ESLintとPrettierの「本当の役割」を定義する
まず、ツールを正しく理解しましょう。
- ESLint（コードの守護神）: 「コードが正しい論理で書かれているか」「安全か」をチェックします。これは品質の番人です。
- Prettier（見た目の調律師）: 「カッコはどこで改行するか」「セミコロンはあるか」を整えます。これは可読性の調律師です。
多くの初心者は、この二つが衝突して「Lintエラーが消えない！」と焦ります。大切なのは、「整形はPrettierに任せ、論理はESLintに任せる」という役割の分離です。
—
2. なぜ `eslint-disable` を禁止すべきなのか？
`// eslint-disable-next-line` を書くことは、プロジェクトの「品質基準」をその場限りの例外で破壊する行為です。これが増えると、コードベースは「何が正解で、何がバグなのか」を判別できない、混沌とした状態に陥ります。
私たちが目指すのは、「コメントで誤魔化すのではなく、設定を適正化してエラーを解消する」という設計思想です。
—
3. 実践：厳格なLint環境の構築と「禁止ルール」の実装
まずは、開発環境を構築します。ターミナルを開き、以下のコマンドを叩いてください。
必要なライブラリを一括でインストール
npm install –save-dev eslint prettier eslint-config-prettier eslint-plugin-prettier
ESLintのカスタム設定（.eslintrc.json）
ここで、`no-restricted-syntax` を使い、特定の条件下でコメントによる無効化を封じます。
{
“plugins”: [“prettier”],
“extends”: [“eslint:recommended”, “plugin:prettier/recommended”],
“rules”: {
“prettier/prettier”: “error”,
// ここが肝：eslint-disableコメントを原則禁止する設定
“no-restricted-syntax”: [
“error”,
{
“selector”: “Program > :matches(LineComment, BlockComment)”,
“message”: “eslint-disableコメントは使用禁止です。ルール設定を見直すか、コードを修正してください。”
}
]
}
}
なぜこれが必要か？: この設定により、開発者が安易に `eslint-disable` を使おうとした瞬間、エディタが赤く警告し、ビルドを強制停止させます。これにより、「問題があるなら、隠さずに解決せよ」という厳格な文化が強制的に醸成されます。
—
4. HelloWorld的な動作確認：あえてエラーを起こす
設定が正しいか、わざとエラーを出して確認しましょう。`app.js` というファイルを作成します。
// あえてルールを無視しようとする
// eslint-disable-next-line
const message = “Hello, World!”;
console.log(message);
このファイルを保存した瞬間、VSCodeなどのエディタ上で `eslint-disable` の行に赤い波線が引かれ、以下のエラーが出るはずです。
> Error: eslint-disableコメントは使用禁止です。ルール設定を見直すか、コードを修正してください。
これこそが、あなたのコードを「最高品質」へと導くための最初の警報です。
—
5. アーキテクトからのアドバイス：どう「解決」すべきか？
もしLintエラーが出て、どうしても修正できないときは、以下の手順を辿ってください。
1. ルールの緩和を検討する: そのルールがプロジェクト全体で不要なら、`eslint-disable` で逃げるのではなく、`.eslintrc.json` の `rules` を修正して、ルール自体を緩和してください。
2. リファクタリングの機会と捉える: エラーが出るということは、あなたのコードが「ESLintが危ないと判断する書き方」をしているという証拠です。コードの書き方を変えれば、エラーは自然と消えます。
—
まとめ：毎日のコーディングが劇的に楽になる理由
「コメントで無効化」という逃げ道を塞ぐと、最初は苦しいかもしれません。しかし、一週間もすれば、あなたは「Lintエラーが出ないクリーンなコードを書く癖」が身についていることに気づくはずです。
バグが減り、チームメンバーとのコードレビューで「なぜ無効化してるの？」と問い詰める不毛な時間がなくなります。規律こそが、開発速度を最大化する唯一の近道です。
さあ、今すぐプロジェクトから `eslint-disable` を削除し、コードの品格を取り戻しましょう。あなたのコードベースが、誰からも愛される美しいものになることを確信しています。