ESLintとPrettierの「沼」から脱出し、開発の本質へ集中する極意
開発の現場で「ESLintとPrettierの設定が面倒で、いつもコピペで済ませている」という声をよく耳にします。しかし、これらは単なる「コードを綺麗にするツール」ではありません。これらは、あなたの脳のメモリを節約し、論理的なコードを書くための認知負荷を劇的に下げるための「外部脳」です。
今日は、巷に溢れる「とりあえず`recommended`を入れておけばOK」という浅い理解を卒業し、なぜその設定が必要なのか、どうすればチームの開発生産性を最大化できるのか、そのアーキテクチャの本質に迫ります。
—
1. なぜ「recommended」だけでは足りないのか？
ESLintの`eslint:recommended`は、あくまで「バグを引き起こしやすい記述」を警告する最低限のセーフティネットです。しかし、現代のReactやNext.jsの開発では、それだけでは不十分です。
理由は明確です。「フレームワーク固有の落とし穴」を検知できないからです。
例えば、Reactの`useEffect`の依存配列の漏れや、Next.jsのLinkコンポーネントの不適切な使い方など、ランタイムエラーに直結するミスを、静的解析の段階で「コードを書いている最中」に叩き潰す必要があります。
私たちが目指すべき「理想の静的解析」とは
1. 人間が判断しなくていいことは、すべてツールに任せる。
2. フォーマット（見た目）とLint（論理的整合性）を完全に分離する。
3. ルール同士の衝突を物理的に排除する。
—
2. 最強の布陣を構築する：インストール戦略
まずは、ツール間の衝突を避けるための「黄金の3点セット」をインストールします。
必要なライブラリをまとめてインストールします
eslint-config-prettier: Prettierと競合するESLintのルールを無効化する「必須」ツール
eslint-plugin-prettier: 逆にESLintのルールとしてPrettierを実行するプラグイン
npm install –save-dev eslint prettier eslint-config-prettier eslint-plugin-prettier
なぜこれらが必要なのか？
ESLintは「コードの書き方（論理）」をチェックし、Prettierは「コードの見た目（スタイル）」を整えます。この2つは役割が異なりますが、重なる部分（例：インデントの深さなど）で必ず喧嘩をします。これを解消するのが`eslint-config-prettier`です。
—
3. 実践：環境別おすすめ設定（.eslintrc.js）
ここでは、モダンなNext.jsプロジェクトを例に、保守性が高く、かつ「無駄な警告で開発者をイライラさせない」設定を紹介します。
module.exports = {
env: {
browser: true, // ブラウザ環境のグローバル変数を許可
node: true, // Node.js環境のグローバル変数を許可
es2021: true,
},
extends: [
‘eslint:recommended’,
‘plugin:react/recommended’, // Reactのルールを追加
‘plugin:react-hooks/recommended’, // Hooksのルール（重要！）
‘plugin:@next/next/recommended’, // Next.js特有の最適化チェック
‘prettier’, // 最後に追加することで、他のルールとの競合を無効化する
],
rules: {
// 「warn」にするか「error」にするかはチームの文化で決める
‘react/react-in-jsx-scope’: ‘off’, // Next.jsでは不要なため無効化
‘no-console’: process.env.NODE_ENV === ‘production’ ? ‘error’ : ‘warn’,
},
settings: {
react: {
version: ‘detect’, // インストールされているReactのバージョンを自動検出
},
},
};
この設定の「魂」
- `plugin:react-hooks/recommended`: これを入れないと、`useEffect`の依存配列漏れに気づけません。バグの温床を未然に防ぐ最強のガードマンです。
- `react/react-in-jsx-scope: ‘off’`: 古いReactの書き方に縛られず、モダンな開発環境に最適化させています。無駄なルールを消すことも、設定の重要な仕事です。
—
4. 精度高い「HelloWorld」的動作確認
設定が正しく効いているか、以下の手順で確認しましょう。
1. わざとエラーを書く: `const x = 1` と書いたのに、どこにも使わないコードを書いてみてください。
2. コマンド実行: `npx eslint your-file.js`
3. 結果を確認:
もし正しく設定されていれば、`no-unused-vars`というエラーが返ってきます。
4. 自動修復の確認: `npx eslint –fix your-file.js` を実行し、コードが勝手に綺麗になれば勝利です。
—
5. 最後に：ツールに支配されるな
設定ファイルをいじりすぎると、時として「ツールを動かすためのツール」に時間を取られるようになります。これが開発者の本末転倒です。
重要なのは、「このルールは何のために存在するのか？」という問いを持ち続けることです。プロジェクトが成長し、チームメンバーが増えれば、必要なルールは変わります。ルールは固定された聖典ではなく、チームを守るための「進化する盾」です。
今日設定したこの基盤があれば、あなたは「コードの整合性」という細部に神経をすり減らすことなく、「どんな機能をユーザーに届けるか」という本質的な設計に、100%の脳のリソースを注ぎ込めるようになるはずです。
毎日のコーディングが、少しだけ、いや劇的に楽になるはずです。ぜひ、今日からあなたのプロジェクトに導入してみてください。