【2024年版】ESLint × Prettier：なぜこの組み合わせが「最強」なのか、設定の深淵を解き明かす
こんにちは。エンジニアとしてコードを書くとき、あなたは「コードの良し悪し」を何で判断していますか？
もし、インデントのズレやセミコロンの有無でレビューを消費しているなら、それは非常に勿体ないことです。機械的なルールは機械に任せ、人間はロジックという「本質」に集中する。 これこそが、一流のエンジニアが開発環境に求める絶対条件です。
今回は、JavaScript/TypeScript開発における二大巨頭、ESLintとPrettierを完璧に調和させるための「決定版設定」を解説します。
—
1. そもそも、なぜ2つ必要なのか？
まず、この2つのツールの役割を明確にしましょう。ここを混同していると、設定の泥沼に足を踏み入れることになります。
- ESLint（コードの「質」を守る番人）:
コード内のバグになりそうなパターン（未使用変数や型定義の漏れなど）を見つけ出し、修正を促す静的解析ツールです。「どう書くべきか」というロジックの正しさを保証します。
- Prettier（コードの「見た目」を整える職人）:
インデント、クォーテーションの統一、改行位置など、コードの「見た目」だけを強制的に整えるフォーマッターです。「どう見えるか」の統一に特化しています。
「なぜ分けるのか？」
ESLintで無理やり見た目まで制御しようとすると、設定が肥大化し、解析速度が落ちます。一方、Prettierは解析能力を持たず、見た目だけに全振りしています。この「分業」こそが最強のアーキテクチャなのです。
—
2. 決定版！設定の要「2つのパッケージ」を理解する
多くの初心者がここで挫折します。インストールすべきは以下の2つです。
1. `eslint-config-prettier`: ESLintの「見た目に関するルール」を全て無効化する設定。
2. `eslint-plugin-prettier`: （重要：2024年以降は非推奨になりつつあります）
なぜ「eslint-plugin-prettier」は避けるべきか？
かつては推奨されていましたが、現在は「ESLintは質、Prettierは見た目」と役割を完全に分離する方が遥かに高速で安定します。
現在は、「Prettierはエディタの保存時実行（Format on Save）に任せる」のが、最も堅牢で現代的なアプローチです。
—
3. 最速セットアップ：現場で即戦力となる構成
それでは、プロジェクトに導入してみましょう。以下のコマンドを実行してください。
必要なライブラリをインストール
npm install –save-dev eslint prettier eslint-config-prettier
設定ファイル（.eslintrc.json）の構築
プロジェクトのルートに `.eslintrc.json` を作成し、以下のように記述してください。
{
“extends”: [
“eslint:recommended”,
“prettier” // これが重要！eslintの見た目ルールを無効化し、Prettierと衝突させない
],
“env”: {
“node”: true,
“es2022”: true
},
“rules”: {
// ここには「コードの質」に関するルールのみを記述
“no-unused-vars”: “warn”,
“no-console”: “off”
}
}
Prettierの設定（.prettierrc）
ルートに `.prettierrc` を作成します。
{
“semi”: true, // セミコロンを強制
“singleQuote”: true, // シングルクォーテーションに統一
“tabWidth”: 2, // インデントは2スペース
“trailingComma”: “es5” // 末尾のカンマをES5仕様にする
}
—
4. 動作確認：現場での「HelloWorld」的検証
正しく設定できているか、わざと汚いコードを書いて確認しましょう。
検証用の `app.js` を作成:
const user=”Taro” // スペースなし、シングルクォーテーションもルール外
function hello(){
console.log(“Hello”)
}
1. Prettierのテスト: VS Codeの設定で「Format on Save」をONにしていれば、ファイルを保存した瞬間にインデントが整い、クォーテーションが統一されます。
2. ESLintのテスト: ターミナルで `npx eslint app.js` を実行してください。もしルールに違反していれば、即座に指摘が飛んできます。
—
5. 最後に：なぜこれが「開発効率」を爆上げするのか
この設定を導入する最大のメリットは、「チーム全員が同じルールでコードを書くこと」にあります。
コードレビューの際、「ここのインデントが…」「クォーテーションが…」といった不毛な議論がこの世から消滅します。 あなたの脳のリソースは、より難解なアルゴリズムや、ビジネスロジックの最適化にのみ使われるようになるのです。
今日からこの設定を使い、「ルールを守る機械」から「価値を生み出すアーキテクト」への一歩を踏み出してください。あなたの開発ライフが、驚くほど軽やかになるはずですよ。