既存プロジェクトを「汚さずに」ESLintを導入する：大規模開発における静的解析の外科手術
大規模なコードベースにESLintを導入する際、最も恐ろしいのは「一括修正（`–fix`）によるコミット履歴の破壊」と「無数の警告による開発者の疲弊」です。
テックリードとして、私はESLintを単なる「コードチェッカー」ではなく、「チームの認知負荷を最小化するガードレール」と定義しています。本稿では、既存のレガシーコードを破壊することなく、ESLintを段階的に浸透させ、最終的にチームの開発生産性を極限まで高めるための「外科的手法」を伝授します。
—
1. 破壊的変更を回避する「防御的導入」の極意
既存プロジェクトにESLintを入れる際、いきなり厳格なルールを適用してはいけません。以下の手順で「まずは観測し、次に警告し、最後に強制する」という段階を踏みます。
ステップ1：現状を「封じ込める」
まずは、既存のコードに存在する無数の違反を無視するために、`.eslintignore` を活用します。しかし、単に全ファイルを無視するのではなく、`package.json` に専用のスクリプトを定義し、「現在の負債」を確定させることから始めます。
既存の違反を解消せずに、新規ファイルのみを対象にするためのフラグ戦略
“lint:new”: “eslint –ext .ts,.tsx –report-unused-disable-directives .”
ここで重要なのが `–report-unused-disable-directives` です。これは「必要のない `eslint-disable`」を警告してくれる神フラグです。これを使うことで、「本来なら直せるはずなのに、無意味に握りつぶされている警告」を可視化できます。
ステップ2：ルールを「警告」から始める
`.eslintrc.js` の `rules` 設定では、最初から `error` を指定してはいけません。まずは `warn` で設定し、CIに影響を与えないようにします。
// .eslintrc.js の初期構成
module.exports = {
rules: {
// 既存コードを壊さないよう、まずは警告レベルで導入する
‘@typescript-eslint/no-explicit-any’: ‘warn’,
‘no-unused-vars’: ‘warn’,
}
};
—
2. チーム開発を加速させる「神プラグイン」と「設定共有」
静的解析は、書いている最中にフィードバックが返ってこなければ意味がありません。
必須プラグインの選定
1. `eslint-plugin-import`: インポート順序を自動整理。依存関係のスパゲッティ化を物理的に防ぎます。
2. `eslint-plugin-sonarjs`: 複雑度（Cyclomatic Complexity）が高い関数を検出し、リファクタリングのタイミングを可視化します。
3. `eslint-plugin-unused-imports`: 未使用インポートを自動削除。これだけでコードベースの重量が数パーセント減ります。
プロフェッショナルの設定共有戦略
設定を個人のPC環境に依存させてはいけません。チーム全員が同じルールセットで戦うために、設定ファイルは `eslint-config-custom` のようなパッケージとして切り出すか、モノレポ構成であれば共通の `config` ディレクトリで管理し、`extends` で読み込ませるのが鉄則です。
// .eslintrc.json のベストプラクティス構成
{
“extends”: [
“eslint:recommended”,
“plugin:@typescript-eslint/recommended”,
“prettier” // Prettierとの競合を完全に排除する必須の終端設定
],
“rules”: {
// チームの規約を明文化：自動修正可能なものだけをerrorにする
“indent”: [“error”, 2],
“quotes”: [“error”, “single”]
}
}
—
3. 生産性を極限まで高める「IDE連携」と「ショートカット」
開発者が「lintが走るまで待つ」のは時間の無駄です。VS Codeを使用している場合、以下の設定はもはや義務です。
`settings.json` に刻むべき一行
{
“editor.codeActionsOnSave”: {
// 保存時に自動でESLintエラーを直し、Prettierをかける
“source.fixAll.eslint”: true,
“source.fixAll.format”: true
}
}
この設定により、開発者は「コードを書いて `Ctrl+S` (または `Cmd+S`) を押す」だけで、静的解析と整形が完了します。「lintエラーを直すためにコマンドを打つ」というコンテキストスイッチを脳から完全に排除するのです。
知る人ぞ知るショートカット：`Quick Fix`
エラー箇所にカーソルを合わせ、`Cmd + .` (Win: `Ctrl + .`) を押して `Fix all auto-fixable problems` を選択してください。これを使いこなすだけで、リファクタリングの速度は3倍に跳ね上がります。
—
4. 最後に：アーキテクトからの助言
ESLintとPrettierの導入で最も避けるべきは、「ルールを厳しくしすぎて、開発者がlintを無効化する」という本末転倒な事態です。
- 自動化できるものはすべて自動化せよ（Prettierは最強の自動化ツールです）。
- 人間に判断させるべきルールと、機械に任せるべきルールを分けよ（人間は設計に集中し、機械に構文を任せる）。
- 「なぜそのルールが必要か」をREADMEに書け（ルールの意図が不明な時、エンジニアはそれをノイズとみなします）。
既存コードベースへの導入は、一度に完遂しようとせず、小さなコミットの積み重ねで行ってください。今日からあなたのプロジェクトが、より堅牢で、より「クリーン」な領域へ進むことを願っています。
さあ、まずは `.eslintignore` の作成から始めましょうか。