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 には indent
、quotes
、semi
などのフォーマット関連ルールが存在します。これらのルールが Prettier の自動フォーマット機能と衝突してしまうのです。
typescript// 競合例: セミコロンの設定
// ESLint 設定: "semi": ["error", "always"]
// Prettier 設定: "semi": false
const message = 'Hello World'; // Prettier がセミコロンを削除
// ^ ESLint が「セミコロンがない」とエラー
この競合により、開発者は以下のような問題に直面します:
- 保存時の無限ループ: Prettier が削除したセミコロンを ESLint が再度要求する
- CI/CD での失敗: ローカルでは問題なくても、CI 環境でリント エラーが発生
- チーム内での設定バラつき: 開発者ごとに異なる設定を使用してしまう
開発現場でよく遭遇する問題
実際の開発現場では、以下のような場面で 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: 2 | tabWidth: 2 | 正常動作 |
B さん | indent: 4 | tabWidth: 4 | 正常動作 |
C さん | indent: 2 | tabWidth: 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.json
の extends
配列の 最後 に 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 の安定化: 環境差異による失敗の削減
導入時のベストプラクティス
- eslint-config-prettier は extends 配列の最後に配置
- VS Code 設定でフォーマットオンセーブを有効化
- CI/CD パイプラインでの自動チェック導入
- Git フックによるコミット前チェックの設定
この設定により、開発者はフォーマットの心配をすることなく、ビジネスロジックの実装に集中できるようになります。
Modern Web 開発における品質担保のためにも、ぜひ eslint-config-prettier を活用して、より良い開発体験を実現してください。
関連リンク
- article
ESLint と Prettier の競合を完全解決:eslint-config-prettier 徹底解説
- article
ESLint でアクセシビリティを向上させる a11y ルール活用術
- article
Lerna × ESLint:マルチパッケージ環境での効率的な Lint 運用
- article
ESLint ルールの重要度設定:error・warn・off の使い分け戦略
- article
Angular 開発者必見!ESLint で Angular プロジェクトを品質管理
- article
ESLint の設定継承とマージロジックを完全理解する
- article
Svelte と GraphQL:最速データ連携のススメ
- article
Lodash の throttle・debounce でパフォーマンス最適化
- article
LangChain で RAG 構築:Retriever・VectorStore の設計ベストプラクティス
- article
Storybook で学ぶコンポーネントテスト戦略
- article
状態遷移を明文化する:XState × Jotai の堅牢な非同期フロー設計
- article
Jest で DOM 操作をテストする方法:document・window の扱い方まとめ
- blog
iPhone 17シリーズの発表!全モデルiPhone 16から進化したポイントを見やすく整理
- blog
Googleストアから訂正案内!Pixel 10ポイント有効期限「1年」表示は誤りだった
- blog
【2025年8月】Googleストア「ストアポイント」は1年表記はミス?2年ルールとの整合性を検証
- blog
Googleストアの注文キャンセルはなぜ起きる?Pixel 10購入前に知るべき注意点
- blog
Pixcel 10シリーズの発表!全モデル Pixcel 9 から進化したポイントを見やすく整理
- blog
フロントエンドエンジニアの成長戦略:コーチングで最速スキルアップする方法
- review
今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
- review
ついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
- review
愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
- review
週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
- review
新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
- review
科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来