ESLintは「お守り」ではない。開発速度を加速させる「静的エンジン」へ昇華させる技術
多くのエンジニアが陥る罠がある。「とりあえず `eslint:recommended` を入れて、あとは適当にWarningを消す」という運用だ。これは、最高級のスポーツカーにママチャリのブレーキを付けているようなものだ。
静的解析ツールは、単なるコードのチェックリストではない。「人間がコードレビューという高コストな脳のメモリを割くべきではない領域」をすべて自動化し、純粋なビジネスロジックの設計に集中するための武器である。
本稿では、推奨設定の向こう側にある、チームの生産性を極限まで引き上げるアーキテクチャ設計を伝授する。
—
1. 「recommended」の幻想を捨てる
`eslint:recommended` はあくまで「最低限のバグを防ぐ」ためのものだ。実務において、我々が本当に排除したいのは「書き方の揺れ」や「将来のバグの温床となる複雑性」である。
推奨を超えた「神プラグイン」構成
フレームワークごとの最適解は、以下のプラグインを軸に構成する。
- `eslint-plugin-perfectionist`: インポート文やオブジェクトのキー、型定義を自動でソートする。Gitのコンフリクトを劇的に減らし、脳の認知負荷を下げる。
- `eslint-plugin-sonarjs`: 循環複雑度（Cyclomatic Complexity）を可視化し、ネストが深いコードに警告を出す。リファクタリングのタイミングを自動で教えてくれる。
- `eslint-plugin-unused-imports`: 使われないインポートを検知し、保存時に自動削除する。
—
2. フレームワーク別・鉄板構成のベストプラクティス
設定ファイルは「巨大なJSON」にしてはいけない。`overrides`（または新しいFlat Configの `files`）を使い、役割ごとに分割管理するのが鉄則だ。
プロフェッショナルな `.eslintrc.js` (Flat Config対応)
import js from “@eslint/js”;
import ts from “@typescript-eslint/eslint-plugin”;
import reactHooks from “eslint-plugin-react-hooks”;
import perfectionist from “eslint-plugin-perfectionist”;
export default [
// 1. 基本設定：すべての環境に適用する「厳格な」ベース
js.configs.recommended,
{
rules: {
“no-console”: “warn”, // 本番環境で残さないための注意喚起
“prefer-const”: “error”, // 再代入のない変数は必ずconstにする
}
},
// 2. TypeScript専用：型安全を強制する
{
files: [“/.ts”, “/.tsx”],
plugins: { “@typescript-eslint”: ts },
rules: {
“@typescript-eslint/no-explicit-any”: “error”, // anyの使用を禁止し、型安全を死守
“@typescript-eslint/no-unused-vars”: [“error”, { “argsIgnorePattern”: “^_” }]
}
},
// 3. React専用：Hooksの依存配列ミスを許さない
{
files: [“/.tsx”],
plugins: { “react-hooks”: reactHooks },
rules: {
“react-hooks/rules-of-hooks”: “error”, // Hooksのルール違反を即座に検知
“react-hooks/exhaustive-deps”: “warn” // 依存配列の漏れを警告
}
},
// 4. ソートの自動化：チーム開発の衝突を未然に防ぐ
{
plugins: { perfectionist },
rules: {
“perfectionist/sort-imports”: [“error”, { “type”: “natural” }],
“perfectionist/sort-objects”: [“error”, { “partition-by-comment”: true }]
}
}
];
—
3. 開発速度を爆速にする「運用の掟」
どれだけ良い設定をしても、開発者が無視すれば意味がない。以下の3つのアプローチで「強制力」を持たせる。
① Lintの修正は「保存時」に完了させる
VS Codeの `settings.json` で、LintとPrettierを保存時に自動適用する設定は必須だ。
{
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit”, // ESLintの自動修正を強制
“source.formatDocument”: “explicit” // Prettierの整形を強制
},
“editor.formatOnSave”: true
}
② チームで設定を共有化する：`.editorconfig` の併用
IDEの設定差異が原因で「保存するたびにインデントが全書き換えされる」という悲劇を防ぐため、`.editorconfig` をルートに置く。
[]
indent_style = space
indent_size = 2
end_of_line = lf
trim_trailing_whitespace = true
insert_final_newline = true
③ 「lint-staged」によるコミット前の完全防備
`husky` と `lint-staged` を使い、コミット時に「変更されたファイルのみ」をLintする。これにより、CIの待ち時間を減らしつつ、汚いコードがリポジトリに入ることを物理的に阻止する。
// package.json に記述
“lint-staged”: {
“.{js,ts,tsx}”: [
“eslint –fix”, // 自動修正を試みる
“prettier –write” // その後、整形を確定させる
]
}
—
4. 最後に：テックリードからの提言
コード品質をツールに委ねることは、「人間は人間にしかできない、より創造的な判断に時間を投資する」という意志決定である。
「このルールは厳しすぎるのではないか？」と悩む必要はない。ルールは、チームの平均的な技術レベルを、トップレベルの基準まで引き上げるための「教育装置」でもある。
最初は警告に追われるかもしれない。だが、1ヶ月後には、あなたのチームから「インデントの修正」や「使われていない変数の削除」という無駄な議論が消滅しているはずだ。その時こそ、あなたがエンジニアとして「アーキテクチャの設計」という本質的な仕事に没頭できる時間だ。
今すぐ `npm install` して、チームのOSをアップデートしてほしい。