大規模なプロジェクトにESLintを導入しようとして、`eslint –fix` を実行した瞬間に数千ファイルの差分がGitに現れ、絶望した経験はありませんか？
「コードの品質を上げたいだけなのに、これでは歴史あるコードベースの履歴を汚し、チームを混乱させるだけだ」と諦めるのはまだ早いです。静的解析は「力技」で導入するものではなく、「外科手術」のように慎重に進めるべきものです。
今日は、既存プロジェクトの平穏を保ちつつ、ESLintとPrettierを静かに、しかし確実に浸透させるための「アーキテクト流・段階的導入術」を伝授します。
—
1. なぜ「一括自動整形」が最悪の選択肢なのか
多くのチュートリアルは `eslint –fix .` を推奨しますが、これは罠です。大規模プロジェクトにおいて、コミットログは「コードの歴史」そのものです。一括で全ファイルを書き換えると、`git blame` が破壊され、「誰が、なぜそのロジックを書いたのか」というコンテキストが永久に消失します。
我々が目指すべきは、「今日から書かれるコードは綺麗に、過去のコードは動かさない」という、現実的な妥協点です。
—
2. 段階的導入のための「3ステップ・ストラテジー」
Step 1: 警告（Warning）から始める「静かなる監視」
まずは、コードを直すのではなく、問題を見つけることから始めます。
1. インストール
# 必要なパッケージをインストール（eslint-config-prettierは必須）
npm install –save-dev eslint prettier eslint-config-prettier eslint-plugin-prettier
2. 設定ファイル (`.eslintrc.js`) の作成
ポイントは `rules` を `warn` に設定することです。これにより、CIは落ちず、開発者のエディタに波線が出るだけの状態を作ります。
module.exports = {
extends: [
‘eslint:recommended’,
‘prettier’ // Prettierと競合するルールを無効化する魔法のプラグイン
],
rules: {
// いきなりerrorにせず、まずは警告レベルで検知する
‘no-unused-vars’: ‘warn’,
‘eqeqeq’: ‘warn’,
}
};
Step 2: 既存コードを「除外」し、聖域を守る
既存のレガシーコードに対しては、`.eslintignore` を駆使して解析対象から外します。
- .eslintignore
# プロジェクトルートの全ファイルを一旦無視
/
# 新しく書くコードのディレクトリだけを明示的に対象にする
!src/features/new-module/
これにより、開発者は「新しい機能を作る時だけESLintの洗礼を受ける」という、精神的負荷の少ない環境に移行できます。
Step 3: `report-unused-disable-directives` で腐敗を防ぐ
これが、プロのアーキテクトが必ず設定する「守護神」です。`eslint-disable` を乱用して警告を隠蔽するエンジニアは必ず現れます。それを防ぐのがこのオプションです。
// .eslintrc.js
module.exports = {
// …設定
reportUnusedDisableDirectives: true, // 不要になったeslint-disableをエラーとして検知する
};
これを設定しておくと、ルールが修正された際に不要になった警告回避コメントが即座にエラーとして指摘されます。コードの陳腐化を許さないための、非常に強力な防波堤です。
—
3. なぜPrettierを併用するのか？
ESLintは「論理的なバグ（書き方のミス）」を、Prettierは「見た目（インデントや改行）」を管理します。
初心者が最も陥りやすい罠は、ESLintにコード整形までやらせることです。ESLintで「インデントが違う」と怒られ、Prettierで「改行が違う」と怒られる。このダブルパンチは開発体験を著しく損ないます。
- ESLint: コードの質を担保する（論理・静的解析）
- Prettier: コードの見た目を統一する（美学・フォーマット）
この役割分担を明確にし、`eslint-config-prettier` を使って「Prettierと競合するESLintのルール」を全殺しにするのが、現代のJS/TS開発における最適解です。
—
4. 最後に：なぜこれが必要なのか
あなたが今、面倒な設定をしているこの瞬間、未来のあなたが「なぜこのコードはこんなに脆いのか」と頭を抱える時間が削除されています。
静的解析ツールは単なる「説教ツール」ではありません。「チーム全員が同じ言語で話すための辞書」です。これを導入することで、レビューで「セミコロンが足りない」といった生産性の低い議論が消滅し、よりクリエイティブな「アーキテクチャの議論」に時間を使えるようになります。
まずは怖がらず、`warn` レベルから、特定のディレクトリから。小さく始めて、組織の文化を少しずつアップデートしていってください。それが、世界最高峰のエンジニアへの第一歩です。