T-CREATOR

ESLint と Prettier の競合を完全解決:eslint-config-prettier 徹底解説

ESLint と Prettier の競合を完全解決:eslint-config-prettier 徹底解説

現代のフロントエンド開発において、ESLint と Prettier は欠かせないツールとなっています。しかし、この 2 つを同時に使うと設定が競合してしまい、開発効率が大幅に下がってしまうことがあります。

本記事では、eslint-config-prettier を使って ESLint と Prettier の競合を完全に解決する方法を、基礎から応用まで段階的にご説明いたします。これで、もう設定の競合に悩まされることはありません。

背景

ESLint と Prettier の役割の違い

まず、ESLint と Prettier がそれぞれ何を担当しているのかを整理してみましょう。

ESLint は コード品質の検証 を行うリンターツールです。変数の未使用チェック、型の不整合、潜在的なバグの発見などを担当します。

typescript// ESLint が検出する問題例
let unusedVariable = 'これは使われていない'; // unused-vars ルール
if ((value = 10)) {
  // assignment-in-condition ルール
  console.log('代入演算子を使っている');
}

一方、Prettier は コードフォーマットの統一 を行うフォーマッターです。インデント、改行、クォートの種類などの見た目を整えることに特化しています。

typescript// Prettier が整形する例
// Before: 手動で書いたフォーマット
const user = {
  name: 'John',
  age: 30,
  email: 'john@example.com',
};

// After: Prettier による整形
const user = {
  name: 'John',
  age: 30,
  email: 'john@example.com',
};

この役割分担により、ESLint がコードの品質を、Prettier が見た目の統一を担当するという理想的な開発環境が構築できます。

以下の図で、両者の責任範囲を整理してみましょう。

mermaidflowchart LR
  code[ソースコード] --> eslint[ESLint]
  code --> prettier[Prettier]

  eslint --> quality[コード品質チェック]
  eslint --> bugs[潜在バグ検出]
  eslint --> standards[コーディング規約]

  prettier --> format[フォーマット統一]
  prettier --> indent[インデント調整]
  prettier --> quotes[クォート統一]

  quality --> result[高品質なコード]
  bugs --> result
  standards --> result
  format --> result
  indent --> result
  quotes --> result

図で理解できる要点:

  • ESLint は論理的な問題を検出
  • Prettier は視覚的な統一を実現
  • 両者が協力して高品質なコードを生成

なぜ競合が起こるのか

ESLint と Prettier の競合が発生する理由は、両者がフォーマットに関するルールを重複して持っている ためです。

ESLint には indentquotessemi などのフォーマット関連ルールが存在します。これらのルールが Prettier の自動フォーマット機能と衝突してしまうのです。

typescript// 競合例: セミコロンの設定
// ESLint 設定: "semi": ["error", "always"]
// Prettier 設定: "semi": false

const message = 'Hello World'; // Prettier がセミコロンを削除
//                           ^ ESLint が「セミコロンがない」とエラー

この競合により、開発者は以下のような問題に直面します:

  1. 保存時の無限ループ: Prettier が削除したセミコロンを ESLint が再度要求する
  2. CI/CD での失敗: ローカルでは問題なくても、CI 環境でリント エラーが発生
  3. チーム内での設定バラつき: 開発者ごとに異なる設定を使用してしまう

開発現場でよく遭遇する問題

実際の開発現場では、以下のような場面で ESLint と Prettier の競合が問題となります。

チーム開発での混乱 新しいメンバーがプロジェクトに参加した際、ESLint エラーが大量に発生して作業が進まない事例が頻発しています。

レビューでの無駄な議論 Pull Request で「なぜここだけインデントが違うのか」といったフォーマットに関する議論が発生し、本来議論すべきロジックの部分に集中できません。

デプロイメントの遅延 CI/CD パイプラインで ESLint エラーが発生し、急ぎのバグ修正がデプロイできないという問題も発生します。

課題

具体的な競合エラー事例

実際に開発現場で発生する代表的な競合エラーをご紹介します。これらのエラーに遭遇したことがある方も多いのではないでしょうか。

インデント関連の競合

javascript// ESLint: "indent": ["error", 2]
// Prettier: "tabWidth": 4

function calculateTotal(items) {
  return items.reduce((sum, item) => {
    // Prettier が 4 スペース
    return sum + item.price; // ESLint が 2 スペースを要求
  }, 0);
}

エラーメッセージ:

goerror: Expected indentation of 2 spaces but found 4  indent

クォート設定の競合

javascript// ESLint: "quotes": ["error", "single"]
// Prettier: "singleQuote": false

const greeting = 'Hello World'; // Prettier がダブルクォート
//               ^ ESLint がシングルクォートを要求

console.log('User name: ' + userName); // 混在する結果

エラーメッセージ:

goerror: Strings must use singlequote  quotes

改行とセミコロンの複合問題

javascript// ESLint: "semi": ["error", "always"], "max-len": ["error", { "code": 80 }]
// Prettier: "semi": false, "printWidth": 120

const userConfiguration = {
  theme: 'dark',
  language: 'ja',
  notifications: true,
}; // Prettier がセミコロンを削除し、長い行を維持

この場合、複数のルールが同時にエラーを発生させ、手動での修正が困難になります。

設定の複雑化による問題

競合を手動で回避しようとすると、設定ファイルが複雑化してメンテナンスが困難になります。

複雑化した .eslintrc.js の例

javascriptmodule.exports = {
  extends: ['eslint:recommended'],
  rules: {
    // Prettier との競合を避けるための細かい調整
    indent: 'off', // Prettier に任せる
    quotes: 'off', // Prettier に任せる
    semi: 'off', // Prettier に任せる
    'comma-dangle': 'off',
    'object-curly-spacing': 'off',
    'array-bracket-spacing': 'off',
    'computed-property-spacing': 'off',
    'func-call-spacing': 'off',
    'key-spacing': 'off',
    'keyword-spacing': 'off',
    'space-before-blocks': 'off',
    'space-before-function-paren': 'off',
    'space-in-parens': 'off',
    'space-infix-ops': 'off',
    'space-unary-ops': 'off',
    // さらに多数のルールを個別に無効化...
  },
};

この方法には以下の問題があります:

  • 設定漏れのリスク: 無効化し忘れたルールが競合を引き起こす
  • 保守性の低下: 新しい ESLint ルールが追加されるたびに設定を更新する必要がある
  • 可読性の悪化: 本来の品質チェックルールが設定の中に埋もれてしまう

チーム開発での統一性の課題

チーム開発において、各開発者が独自の設定で作業すると、以下のような問題が発生します。

環境差異による問題

開発者ESLint 設定Prettier 設定結果
A さんindent: 2tabWidth: 2正常動作
B さんindent: 4tabWidth: 4正常動作
C さんindent: 2tabWidth: 4競合エラー

以下の図で、チーム開発での設定統一の重要性を示します。

mermaidflowchart TD
  team[チーム開発] --> dev1[開発者A]
  team --> dev2[開発者B]
  team --> dev3[開発者C]

  dev1 --> config1[設定パターン1]
  dev2 --> config2[設定パターン2]
  dev3 --> config3[設定パターン3]

  config1 --> conflict[設定競合]
  config2 --> conflict
  config3 --> conflict

  conflict --> problems[問題発生]
  problems --> delay[開発遅延]
  problems --> bugs[バグ増加]
  problems --> stress[ストレス増大]

この統一性の欠如により、プロジェクト全体の品質と効率が大幅に低下してしまいます。

解決策

eslint-config-prettier とは

eslint-config-prettier は、ESLint と Prettier の競合を根本的に解決するための設定パッケージです。

このパッケージの仕組みは非常にシンプルで効果的です。Prettier と競合する可能性のある ESLint ルールを 自動的に無効化 してくれます。

eslint-config-prettier の動作原理

mermaidsequenceDiagram
  participant Dev as 開発者
  participant ESLint as ESLint
  participant Config as eslint-config-prettier
  participant Prettier as Prettier

  Dev->>ESLint: コード検証実行
  ESLint->>Config: 競合ルールをチェック
  Config->>ESLint: 競合ルールを無効化
  ESLint->>Dev: 品質チェック結果のみ返却
  Dev->>Prettier: フォーマット実行
  Prettier->>Dev: 整形されたコード

このパッケージには以下の特徴があります:

  • 自動無効化: 手動で個別ルールを無効化する必要がない
  • 継続的な更新: 新しい ESLint ルールへの対応も自動的に行われる
  • 最小限の設定: 設定ファイルに 1 行追加するだけで利用可能

インストールと基本設定

eslint-config-prettier の導入は非常に簡単です。以下の手順で設定できます。

ステップ 1: パッケージのインストール

bash# Yarn を使用する場合
yarn add --dev eslint-config-prettier

# npm を使用する場合
npm install --save-dev eslint-config-prettier

ステップ 2: ESLint 設定ファイルの更新

.eslintrc.js または .eslintrc.jsonextends 配列の 最後prettier を追加します。

javascript// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended', // TypeScript を使用する場合
    'prettier', // 必ず最後に配置
  ],
  // その他の設定...
};

重要なポイント: prettier は extends 配列の最後に配置する必要があります。これにより、他の設定で有効化されたフォーマット関連ルールが確実に無効化されます。

ステップ 3: 設定の検証

eslint-config-prettier には設定が正しく動作しているかを確認するための CLI ツールが付属しています。

bash# 設定検証コマンド
yarn eslint-config-prettier path/to/main.js

# 正常な場合の出力例
No rules that are unnecessary or conflict with Prettier were found.

設定ファイルの最適化

複数のフレームワークやライブラリを使用するプロジェクトでは、それぞれに対応した設定の最適化が必要です。

React プロジェクトの最適化設定

javascript// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:react/recommended',
    'plugin:react-hooks/recommended',
    'prettier', // React関連のフォーマットルールも無効化
  ],
  settings: {
    react: {
      version: 'detect',
    },
  },
};

TypeScript + React プロジェクトの設定

javascriptmodule.exports = {
  parser: '@typescript-eslint/parser',
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
    'plugin:react/recommended',
    'plugin:react-hooks/recommended',
    'prettier', // 全ての競合ルールを無効化
  ],
  parserOptions: {
    ecmaVersion: 2021,
    sourceType: 'module',
    ecmaFeatures: {
      jsx: true,
    },
  },
};

Next.js プロジェクトの包括設定

javascriptmodule.exports = {
  extends: [
    'next/core-web-vitals',
    'prettier', // Next.jsのルールとPrettierの競合も解決
  ],
};

この設定により、フレームワーク固有のルールと Prettier の競合も確実に解決されます。

具体例

プロジェクト別設定パターン

実際のプロジェクトタイプ別に、最適な設定例をご紹介します。

スタンダードな JavaScript プロジェクト

javascript// package.json の devDependencies
{
  "eslint": "^8.50.0",
  "prettier": "^3.0.0",
  "eslint-config-prettier": "^9.0.0"
}
javascript// .eslintrc.js
module.exports = {
  env: {
    browser: true,
    es2021: true,
    node: true,
  },
  extends: ['eslint:recommended', 'prettier'],
  parserOptions: {
    ecmaVersion: 'latest',
    sourceType: 'module',
  },
};
json// .prettierrc
{
  "semi": true,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2
}

TypeScript + React プロジェクト(推奨設定)

プロフェッショナルなフロントエンド開発で最もよく使われる構成です。

javascript// .eslintrc.js
module.exports = {
  parser: '@typescript-eslint/parser',
  env: {
    browser: true,
    es2021: true,
  },
  extends: [
    'eslint:recommended',
    '@typescript-eslint/recommended',
    'plugin:react/recommended',
    'plugin:react-hooks/recommended',
    'plugin:jsx-a11y/recommended',
    'prettier', // 必ず最後に配置
  ],
  parserOptions: {
    ecmaVersion: 'latest',
    sourceType: 'module',
    ecmaFeatures: {
      jsx: true,
    },
  },
  settings: {
    react: {
      version: 'detect',
    },
  },
  rules: {
    // カスタムルール(フォーマット以外のもの)
    '@typescript-eslint/no-unused-vars': 'error',
    'react/prop-types': 'off', // TypeScript使用時は不要
  },
};

Monorepo プロジェクト(Lerna/Yarn Workspaces)

複数のパッケージを含む大規模プロジェクトでの設定例です。

javascript// ルートディレクトリの .eslintrc.js
module.exports = {
  root: true, // ルート設定であることを明示
  extends: ['eslint:recommended', 'prettier'],
  env: {
    node: true,
  },
  // サブパッケージ固有の設定を上書き可能に
  overrides: [
    {
      files: ['packages/frontend/**/*.{ts,tsx}'],
      extends: [
        '@typescript-eslint/recommended',
        'plugin:react/recommended',
        'prettier',
      ],
    },
    {
      files: ['packages/backend/**/*.ts'],
      extends: [
        '@typescript-eslint/recommended',
        'prettier',
      ],
      env: {
        node: true,
      },
    },
  ],
};

VS Code との連携設定

開発効率を最大化するための VS Code 設定をご説明します。

VS Code 設定ファイル(.vscode/settings.json)

json{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ],
  "prettier.requireConfig": true,
  "editor.rulers": [80], // Prettier の printWidth と合わせる
  "files.associations": {
    "*.json": "jsonc" // コメント付き JSON サポート
  }
}

推奨 VS Code 拡張機能

プロジェクトチーム全体で使用すべき拡張機能を .vscode​/​extensions.json で管理できます。

json{
  "recommendations": [
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint",
    "bradlc.vscode-tailwindcss", // Tailwind使用時
    "ms-vscode.vscode-typescript-next" // TypeScript使用時
  ]
}

保存時の自動修正フロー

以下の図で、VS Code での保存時の処理フローを確認してみましょう。

mermaidflowchart TD
  save[ファイル保存] --> eslint_fix[ESLint自動修正]
  eslint_fix --> prettier_format[Prettier自動フォーマット]
  prettier_format --> result[最終ファイル]

  eslint_fix --> quality[品質問題の修正]
  prettier_format --> format[フォーマット統一]

  quality --> result
  format --> result

  result --> display[エディタに反映]

この設定により、コードの品質チェックと見た目の統一が保存時に自動で実行されます。

CI/CD パイプラインでの活用

継続的インテグレーションでの ESLint と Prettier の活用方法をご紹介します。

GitHub Actions での設定例

yaml# .github/workflows/code-quality.yml
name: Code Quality Check

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main, develop]

jobs:
  lint-and-format:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          cache: 'yarn'

      - name: Install dependencies
        run: yarn install --frozen-lockfile

      - name: Run ESLint
        run: yarn lint

      - name: Check Prettier formatting
        run: yarn prettier --check .

      - name: Run type check (TypeScript)
        run: yarn tsc --noEmit

package.json のスクリプト設定

json{
  "scripts": {
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx",
    "lint:fix": "eslint . --ext .js,.jsx,.ts,.tsx --fix",
    "prettier": "prettier --write .",
    "prettier:check": "prettier --check .",
    "format": "yarn prettier && yarn lint:fix",
    "pre-commit": "yarn prettier:check && yarn lint"
  }
}

Docker コンテナでの実行例

dockerfile# Dockerfile
FROM node:18-alpine

WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile

COPY . .

# リントとフォーマットチェックを実行
RUN yarn lint
RUN yarn prettier:check

# ビルド実行
RUN yarn build

Husky による Git フック設定

コミット前の自動チェックを設定することで、品質の低いコードがリポジトリに入ることを防げます。

bash# Husky のインストール
yarn add --dev husky lint-staged

# Git フックの初期化
yarn husky install
json// package.json
{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,css,md}": ["prettier --write"]
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
}

この設定により、問題のあるコードがコミットされる前に自動的に修正またはエラーとして検出されます。

まとめ

ESLint と Prettier の競合問題は、eslint-config-prettier を使用することで完全に解決できます。

主要なメリット

  • 設定の簡素化: 複雑な個別ルール無効化が不要
  • 保守性の向上: 新しいルール追加時の対応が自動化
  • チーム開発の効率化: 統一された開発環境の構築
  • CI/CD の安定化: 環境差異による失敗の削減

導入時のベストプラクティス

  1. eslint-config-prettier は extends 配列の最後に配置
  2. VS Code 設定でフォーマットオンセーブを有効化
  3. CI/CD パイプラインでの自動チェック導入
  4. Git フックによるコミット前チェックの設定

この設定により、開発者はフォーマットの心配をすることなく、ビジネスロジックの実装に集中できるようになります。

Modern Web 開発における品質担保のためにも、ぜひ eslint-config-prettier を活用して、より良い開発体験を実現してください。

関連リンク