ESLint と Prettier の違いとは？eslint.config.js の設定と使い方【2026年10月】

ESLint は、JavaScript のコードの中から、バグになりそうな書き方や決まりに合わない書き方を見つけて知らせる道具（リンター）です。Prettier は、コードの見た目（空白・改行・セミコロンなど）を決まった形にそろえる道具（フォーマッター）です。Prettier の公式は「整形は Prettier、バグ探しはリンター」と書いていて、2つは役割が違うので、組み合わせて使えます（2026年10月10日時点）。

この記事は、ESLint や Prettier を初めて入れる人と、古い記事の手順で ESLint を入れて動かなかった人に向けて、2つの違い、いまの設定ファイル（eslint.config.js）の書き方、2つを一緒に使うときの設定を、公式の資料に沿って説明します。版は2026年10月10日時点で、ESLint 10.12.0・Prettier 3.9.10・typescript-eslint 8.71.1 です。古い設定ファイル .eslintrc は、ESLint 10 では読まれなくなりました。

コマンドを実行して確かめた結果は、日付と環境（macOS・Node.js 24.13.1・npm 11.8.0、2026年10月10日）を添えて、公式の記述とは分けて書きます。VS Code は動かして確かめていないので、公式の文書に書かれていることだけを説明します。出力の中の長いファイルのパスは、ファイル名だけに短くしています。

ESLint と Prettier の違いは？リンターとフォーマッター

ESLint とは？

ESLint の公式は、ESLint を「ECMAScript/JavaScript のコードの中にあるパターンを見つけて報告する道具で、コードをそろえ、バグを避けることが目的」と説明しています。設定できる JavaScript のリンターで、見つける問題には、実行時のバグになりそうなもの、よいとされる書き方（ベストプラクティス）に沿っていないもの、スタイルの問題があります。

ESLint の中心は「ルール」です。ルールは、1つ1つが「この書き方を見つけたら知らせる」という決まりです。ルールによっては直し方を持っていて、--fix オプションやエディタの拡張で自動で直せます（ルール一覧で 🔧 の印が付いているもの）。提案（suggestion）は自動では当てられず、エディタからだけ使えます。

注意したいのは、ESLint は何も設定しないと何も調べない点です。公式は、共有の設定を使うか、自分でルールを有効にしないと、ESLint はコードを調べない、と書いています。

出典: ESLint 公式: Getting Started・ESLint 公式: Core Concepts

Prettier とは？

Prettier は、「意見を持った（opinionated）」コードフォーマッターと紹介されています。対応する言語は、JavaScript・JSX・TypeScript・CSS（Less・SCSS）・HTML・JSON・GraphQL・Markdown・YAML・Vue・Angular などです。

仕組みの特徴は、元の書き方を捨てて、行の長さを考えながらコードを一から印字し直すことです。たとえば、1行に収まらない関数の呼び出しは、複数行に折られます。また Prettier は、ルールを集めた道具ではありません。公式は、個別の整形ルールを有効・無効にはできず、プログラム全体を印字し直す、と書いています。

使う理由について、公式は「いちばん大きな理由は、スタイルをめぐる議論を終わらせること」と書いています。

出典: Prettier 公式: Introduction・Prettier 公式: Prettier vs. Linters・Prettier 公式: Why Prettier?

違いは「整形のルール」と「品質のルール」

Prettier の公式は、リンターのルールを2種類に分けています。

• 整形のルール: max-len（1行の長さ）や keyword-spacing（キーワードのまわりの空白）など。見た目の決まり
• コードの品質のルール: no-unused-vars（使っていない変数）など。本物のバグを見つけやすい、大事なルール

公式によると、Prettier は前者を不要にしますが、後者には何もしません。そして「Prettier は整形に、リンターはバグ探しに使う」と結んでいます。

	ESLint	Prettier
どんな道具か	リンター。コードの中の問題を見つけて報告する	フォーマッター。コードの見た目をそろえる
やること	問題を報告する。ルールによっては自動で直せる（--fix）	元の書き方を捨てて、コードを一から印字し直す
設定のしかた	ルールを1つずつ有効にする（強さは "off"・"warn"・"error"）	ルールの集まりではない。個別の整形ルールは切り替えられない
得意なこと	使っていない変数など、コードの品質	空白・改行・セミコロン・引用符など、見た目
使っていない変数があると	報告する	何も言わない

最後の行は、手元でも確かめました（2026年10月10日、Prettier 3.9.10・ESLint 10.12.0）。使っていない変数があるファイルでも、prettier --check は問題なしで通り、ESLint だけが no-unused-vars を出しました。実際のコードと出力は、あとの「ぶつからない設定」の節に載せています。

typescript-eslint の公式も、同じ分け方をしています。フォーマッターは空白や改行などを確かめて直す道具、リンターは名前のそろい方やバグなど、ロジックや空白以外のスタイルを確かめて直す道具です。リンターは、たくさんのルールを当てはめるので、数秒以上かかることが多い、とも書かれています。

出典: Prettier 公式: Prettier vs. Linters・typescript-eslint 公式: What About Formatting?

ESLint 自身も、整形からは手を引いている

ESLint には、昔は整形のルールが入っていました。ESLint は、2023年10月26日の公式ブログで、整形のルールを v8.53.0（2023年11月3日公開）で非推奨にすると予告しました。非推奨とは、まだ使えるけれど勧めない、という意味です。非推奨になったルールの例は、indent・semi・quotes・comma-dangle・max-len・no-trailing-spaces・object-curly-spacing などです。理由として、ルールどうしがぶつかり合うことなど、保守の重さが挙げられています。

ESLint の勧めは、整形には ESLint ではなく整形専用の道具を使うことです。勧められているのは Prettier と dprint の2つです。ESLint で続けたい場合は、整形ルールを引き継いだ @stylistic のパッケージもあります。

2026年10月10日時点で、ESLint 10.12.0 でも、これらの整形ルールは削除されず、「非推奨」として残っています。今のルール一覧では、たとえば semi は「@stylistic/eslint-plugin の semi に置き換え」と書かれています。「v10 で削除された」と書いてある記事があったら、公式の文書とは合いません。

もう1つ大事なのは、ESLint 本体の推奨設定も、typescript-eslint の推奨設定も、整形のルールは有効にしないことです。ただし、他の人が作ったプラグインの設定には、整形のルールを有効にするものがあります（それが、あとで説明する「ぶつかる」原因になります）。手元でも、js/recommended だけの設定では、セミコロンの無いコードに ESLint は何も言いませんでした。

出典: ESLint 公式ブログ: Deprecating Formatting Rules・ESLint 公式: ルール一覧（非推奨）・typescript-eslint 公式: What About Formatting?

ESLint の設定ファイルは eslint.config.js ── .eslintrc はどうなった？

ESLint の設定ファイルは、昔は .eslintrc（.eslintrc.json や .eslintrc.js など）でした。いまは eslint.config.js です。古い記事の多くは .eslintrc で説明しているので、まず移り変わりを整理します。

設定の仕組みの移り変わり

新しい設定の仕組みには「flat config」という愛称があり、古い仕組みは「eslintrc」と呼ばれます。flat config では、設定ファイルは「設定オブジェクトの配列」を出力（export）する形で書きます。

時期	できごと
2019年	flat config の RFC（提案の文書）が書かれた
2022年（v8.21.0）	flat config が「試験的・自分で有効にする」形で入った
2024年4月5日（v9.0.0）	flat config が既定になり、eslintrc は正式に非推奨になった。v9 で eslintrc を使い続けるには、環境変数 ESLINT_USE_FLAT_CONFIG を false にする必要があった
2026年2月6日（v10.0.0）	eslintrc の仕組みが完全に削除された
2026年8月6日	ESLint 9 系のサポートが終わった（EOL）

「.eslintrc は v9 で廃止された」という説明を見かけることがありますが、公式の言い方では、v9.0.0 で「非推奨」、v10.0.0 で「削除」です。v9 の間は、環境変数を設定すれば .eslintrc を使えました。

ESLint の公式は、サポートの決まりを「今の版と、1つ前の版の6か月の限定サポート」と書いています。2026年10月10日時点でサポートされているのは 10 系だけで、9 系（9.0.0〜9.39.5）は2026年8月6日にサポートが終わりました。

出典: ESLint 公式ブログ: Flat config rollout plans・ESLint v9.0.0 のお知らせ・ESLint v10.0.0 のお知らせ・ESLint 公式: Version Support

ESLint 10 で .eslintrc だけがあると、どうなる？

ESLint 10 の公式のお知らせは、次のものが読まれなくなった、と書いています。

• .eslintrc.* と .eslintignore のファイル
• 環境変数 ESLINT_USE_FLAT_CONFIG（効かなくなった）
• eslintrc 用のコマンドのオプション（--no-eslintrc・--env・--resolve-plugins-relative-to・--rulesdir・--ignore-path）
• ファイルの中の /* eslint-env */ コメント（エラーとして報告される）

手元で、.eslintrc.json だけがあるフォルダで ESLint 10.12.0 を動かしました。eslint.config.* が見つからないと表示されて止まり、終了コードは 2 でした（終了コードは、コマンドが終わったときの結果の番号で、0 は問題なし、0 以外は問題やエラーがあった、という意味です）。

$ npx eslint .

Oops! Something went wrong! :(

ESLint: 10.12.0

ESLint couldn't find an eslint.config.* file.

From ESLint v9.0.0, the default configuration file is now eslint.config.*.
If you are using a .eslintrc.* file, please follow the migration guide
to update your configuration file to the new format:

https://eslint.org/docs/latest/use/configure/migration-guide

If you still have problems after following the migration guide, please stop by
https://eslint.org/chat/help to chat with the team.

ESLINT_USE_FLAT_CONFIG=false を付けても、出力は同じでした。/* eslint-env node */ と書いたファイルを調べると、次のエラーになりました。

env.js
  1:1  error  /* eslint-env */ comments are no longer supported

✖ 1 problem (1 error, 0 warnings)

つまり、.eslintrc.js を案内している古い記事の手順は、ESLint 10 ではそのままでは動きません。次の「古い設定を移す」か、あとの手順で新しく書き直します。

出典: ESLint v10.0.0 のお知らせ: eslintrc の削除・ESLint 公式: v10 への移行ガイド

古い設定を移す

.eslintrc.json などを移すには、公式の道具があります。

npx @eslint/migrate-config .eslintrc.json

対象は .eslintrc・.eslintrc.json・.eslintrc.yml です。公式は、できるのは出発点の eslint.config.js で、手直しなしで動く保証はない、と書いています。.eslintrc.js は、関数や条件を持ち越せないので、うまく移せません。

手元で .eslintrc.json に対して @eslint/migrate-config 3.0.3 を流すと、eslint.config.mjs ができて、足すパッケージの一覧が表示されました。

Migrating .eslintrc.json

Wrote new config to ./eslint.config.mjs

You will need to install the following packages to use the new config:
- globals
- @eslint/js
- @eslint/eslintrc

You can install them using the following command:

npm install globals @eslint/js @eslint/eslintrc -D

表示どおりに入れると、ESLint が動きました。できた設定には、古い設定を読み替える FlatCompat（@eslint/eslintrc の部品）が使われていました。まだ flat config に対応していない共有設定は、この FlatCompat で読み替えられる、と公式にも書かれています。

書き方で変わるものを表にまとめます。ルールの書き方・プロセッサー（Markdown などの JavaScript 以外のファイルからコードを取り出す仕組み）の書き方・コマンドは、一部のオプションの変更を除いて、移っても変わりません。

古い書き方（eslintrc）	新しい書き方（flat config）
プラグインを文字列の名前で渡す	import（または require）で読み込んだオブジェクトを渡す
env（node: true など）	env は無くなった。globals パッケージを読み込んで languageOptions.globals に入れる
.eslintignore	読まれない。設定の中の ignores に移す（temp.js は **/temp.js と書く）。ドットで始まるファイルは、既定では除かれない
package.json の eslintConfig	使えない。root の設定も無くなった（どの設定ファイルも root: true のように動く）
ファイルの中の /* eslint-env */ コメント	消す。ESLint 10 ではエラーになる

手元でも、globals を入れていない設定では console が no-undef（定義されていない名前）のエラーになりました。

ESLint 9 から 10 に上げる人向けに、公式の移行ガイドは npx codemod @eslint/v9-to-v10 という道具を紹介しています（codemod は、コードの書き換えを自動で行う道具です）。公式は「出発点なので、変更は見直すこと」と書いています。この記事では、この道具は流していません。

出典: ESLint 公式: 設定の移行ガイド・ESLint 公式: v10 への移行ガイド

ESLint 10 で、ほかに変わったこと

• 対応する Node.js: 20.19.0 以上の 20 系、22.13.0 以上の 22 系、24 以上です。21 系と 23 系は対象外です。「対象外」は、公式がサポートしない、という意味で、「動かない」という意味ではありません。手元では、Node.js 20.17.0 と 21.7.1 でも簡単な設定なら動きましたが、20.17.0 の npm で入れると警告が出ました
• 設定ファイルの探し方: ESLint 10 は、調べる各ファイルのフォルダから上に向かって探します（9 では、コマンドを実行したフォルダから探していました）。1回の実行で複数の設定ファイルを使えるので、1つのリポジトリに複数のプロジェクトを置く構成（モノレポ）で役に立つ、と公式は書いています
• 推奨設定: eslint:recommended に、no-unassigned-vars・no-useless-assignment・preserve-caught-error の3つのルールが足されました

出典: ESLint 公式: Getting Started（Prerequisites）・ESLint 公式: v10 への移行ガイド・ESLint v10.0.0 のお知らせ: 設定ファイルの探し方

ESLint を入れて、eslint.config.js を書くには？

ここからは、新しいフォルダで ESLint を動かす手順です。コマンドと出力は、macOS（Node.js 24.13.1・npm 11.8.0）で2026年10月10日に流して確かめたものです。Windows と、pnpm・yarn では流していません。npm・yarn・pnpm の違いと、--save-dev や npx の意味は、こちらの記事で説明しています。

手順1: ESLint を入れる

ESLint の公式の始め方は2通りあります。1つは、対話の質問に答えて設定ファイルを作る npm init @eslint/config@latest です（package.json が先に必要です）。もう1つは、手で入れて、設定ファイルを自分で書く方法です。この記事は後者で説明します。前者の対話式は、流して確かめていません。

npm init -y
npm install --save-dev [email protected] @eslint/[email protected] [email protected]

公式の手順は eslint@latest @eslint/js@latest と書かれています。上は、2026年10月10日時点の最新の版を書いた形です。@eslint/js は、ESLint の推奨ルールが入ったパッケージで、ESLint 本体とは別になっています（ESLint 10.12.0 の依存には入っていないので、自分で入れます）。globals は、ブラウザや Node.js のグローバル変数（どこからでも使える名前。console など）の一覧で、あとで使います。

ESLint をパソコン全体（グローバル）に入れることもできますが、公式は勧めていません。プラグインや共有設定は、どのみちプロジェクトに入れる必要があるからです。

手順2: eslint.config.mjs を書く

設定ファイルの名前は、eslint.config.js・.mjs・.cjs・.ts・.mts・.cts のどれかです（.ts 系は追加の準備が要ります）。プロジェクトの一番上のフォルダに置きます。この記事では .mjs にします。理由はすぐあとの「つまずきやすい点」で説明します。

// eslint.config.mjs
import { defineConfig } from "eslint/config";
import globals from "globals";
import js from "@eslint/js";

export default defineConfig([
	{ files: ["**/*.js"], languageOptions: { globals: globals.node } },
	{ files: ["**/*.js"], plugins: { js }, extends: ["js/recommended"] },
	{ rules: { "prefer-const": "error" } },
]);

この設定がしていることは、次のとおりです。

• 1つ目: .js のファイルで、Node.js のグローバル変数（console など）を使えるようにする
• 2つ目: .js のファイルに、ESLint の推奨ルール（js/recommended）を当てる。公式は「バグになりそうなものを避けるために、みんなに使ってほしいルール」と説明している
• 3つ目: prefer-const（あとで書き換えない変数は const で宣言する）を、エラーとして有効にする

手順3: 動かして、自動で直す

次の app.js を作ります。

const unused = 1
let total = 1 + 2
console.log(total)

npx eslint .

app.js
  1:7  error  'unused' is assigned a value but never used       no-unused-vars
  2:5  error  'total' is never reassigned. Use 'const' instead  prefer-const

✖ 2 problems (2 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

終了コードは 1 でした。npx eslint のうしろにファイルを書かなければ、.（今のフォルダ）と同じ意味になります。

--fix を付けると、自動で直せるものだけが直ります。

npx eslint --fix .

app.js
  1:7  error  'unused' is assigned a value but never used  no-unused-vars

✖ 1 problem (1 error, 0 warnings)

app.js を見ると、let total が const total に書き換わっていました。直せないもの（使っていない変数）だけが、画面に残ります。

このコードには、セミコロンがありません。ESLint の推奨設定は、セミコロンについては何も言いません。セミコロンや引用符をそろえるのは、Prettier の仕事です。

終了コードの意味は、公式によると次のとおりです。

終了コード	意味
0	調べて、エラーが無かった
1	エラーが1つ以上あった（または、警告が --max-warnings の上限を超えた）
2	設定の誤りや、内部のエラーで調べられなかった

ルールの強さは、"off"（0。使わない）・"warn"（1。警告で、終了コードに影響しない）・"error"（2。エラーで、終了コードが 1 になる）です。手元でも、警告だけのときは終了コード 0、エラーがあるときは 1 でした。

つまずきやすい点: npm init -y のあとで eslint.config.js が動かない

ESLint の公式の例は、eslint.config.js を import の書き方で載せています。ところが、npm 11.8.0 の npm init -y は、package.json に "type": "commonjs" と書きます。この状態で、公式の例をそのまま eslint.config.js に置くと、止まります。

SyntaxError: Cannot use import statement outside a module

終了コードは 2 でした。公式の説明では、package.json に "type": "commonjs" があると、eslint.config.js は CommonJS（require と module.exports を使う古い書き方）で書く必要があります。import で書くなら、次のどちらかにします。

• 設定ファイルの名前を eslint.config.mjs にする。手元では、名前を変えただけで動きました
• package.json を "type": "module" にする

typescript-eslint の公式の例が eslint.config.mjs なのも、同じ理由です。.mjs の拡張子は、そのファイルを ES modules（import で書く新しい形式）として扱わせます。ほかの版の npm では、npm init -y が何を書くかは確かめていません。

出典: ESLint 公式: 設定ファイル・typescript-eslint 公式: Getting Started・ESLint 公式: Getting Started・ESLint 公式: コマンドライン

設定ファイルに書ける主な項目

設定ファイルの中の1つ1つの { ... } を「設定オブジェクト」と呼びます。主な項目は、次のとおりです（公式の説明）。

項目	意味
files	その設定を当てるファイル（glob の配列。glob は、**/*.js のように、* でファイル名をまとめて指す書き方です）
ignores	その設定を当てないファイル
extends	ほかの設定を受け継ぐ
languageOptions	globals（グローバル変数）や parser（コードの読み方）など
plugins	プラグイン（ルールなどを足す部品）
rules	使うルール

覚えておくと役に立つ決まりを挙げます。

• 何も指定しないと、ESLint が調べるのは **/*.js・**/*.cjs・**/*.mjs です。.ts などは files に書きます。.ts と .tsx の違いは、こちらの記事で説明しています
• extends を使うときは、files も書くよう公式は勧めています。書かないと、設定が全部のファイルにかかることがあります
• ファイルを調べる対象から外すには、ignores だけを持つ設定オブジェクトを書きます。.eslintignore の代わりです。node_modules と .git は、最初から除かれています
• js/recommended は、推奨のルールをすべて有効にします。js/all は全部のルールで、版が変わるたびに変わるので、公式は本番には勧めていません

設定ファイルを TypeScript（eslint.config.ts）で書く方法もあります。Node.js では、jiti 2.2.0 以上を自分で入れる必要があります。この記事では試していません。

出典: ESLint 公式: 設定オブジェクト・ESLint 公式: files と ignores・ESLint 公式: ファイルを除く・ESLint 公式: TypeScript の設定ファイル

Prettier を入れて、整形するには？

Prettier の入れ方と使い方は、次の手順です。コマンドと出力は、同じ環境で2026年10月10日に流して確かめたものです。

入れる

Prettier の公式は、プロジェクトに版を固定して入れる方法を勧めています（ページに書かれた版は、2026年10月10日時点で 3.9.10 でした）。

npm install --save-dev --save-exact [email protected]
npx prettier --version

--save-exact を付けると、package.json に "prettier": "3.9.10" と、^ を付けずに版が書かれます。公式の理由は、プロジェクトの全員が同じ版の Prettier を使うようにするためです。Prettier は、パッチ版（小さな修正の版）でも、整形の結果が少し変わることがあるからです。

入れずに npx prettier を動かすこともできますが、公式は勧めていません。その時点の最新の版を一時的に取ってくるので、版が固定されず、整形の結果が変わることがあるからです。

次に、空の設定ファイル .prettierrc を作ります。これは、エディタなどに「このプロジェクトは Prettier を使っている」と伝えるためのものです。中身は {} だけです（公式は node --eval "fs.writeFileSync('.prettierrc','{}\n')" というコマンドを載せています）。整形したくないファイルは、.prettierignore に書きます。

# Ignore artifacts:
build
coverage

Prettier は、同じフォルダに .gitignore があれば、その中身にも従います。

動かす

整形する前の app.js です。

const user = {name:"taro",age:20}
function greet(u){return "hello " + u.name}
console.log(greet(user))

公式が「いちばんよく使う」と書いているのは、次の2つです。

• npx prettier . --write: 整形して、ファイルを書き換える。ESLint の --fix に近い（別名 -w）
• npx prettier . --check: 整形済みか確かめるだけで、書き換えない。CI 向け

npx prettier . --check

Checking formatting...
[warn] app.js
[warn] Code style issues found in the above file. Run Prettier with --write to fix.

終了コードは 1 でした。Prettier の終了コードは、公式によると、0 が「全部整形済み」、1 が「整形されていないものがある」、2 が「Prettier 側の問題」です。

npx prettier . --write

.prettierrc 9ms (unchanged)
app.js 6ms
package-lock.json 1ms (unchanged)
package.json 1ms (unchanged)

app.js は次のように変わり、もう一度 --check を流すと「All matched files use Prettier code style!」と出て、終了コードは 0 でした。

const user = { name: "taro", age: 20 };
function greet(u) {
  return "hello " + u.name;
}
console.log(greet(user));

オプションを何も書いていないので、セミコロンが付き、引用符はダブルクォートのままです。

設定を変えたいときは

Prettier の設定は、公式によると、優先順位の高い順に、package.json の "prettier" の欄、JSON か YAML で書いた .prettierrc、.prettierrc.json などのファイル、prettier.config.js などのファイルに書けます。全体（グローバル）の設定は、わざと用意されていません。

主なオプションの既定値は、次のとおりです。

オプション	意味	既定値
printWidth	1行の長さの目安	80
tabWidth	字下げの空白の数	2
useTabs	空白ではなくタブで字下げするか	false
semi	文の最後にセミコロンを付けるか	true
singleQuote	シングルクォートを使うか	false（ダブルクォート）
trailingComma	最後の要素のあとのカンマ	"all"（3.0.0 で "es5" から変わった）

公式の設定例は、次のとおりです（.prettierrc.json か .prettierrc に書きます）。

{
  "trailingComma": "es5",
  "tabWidth": 4,
  "semi": false,
  "singleQuote": true
}

printWidth は、ESLint の max-len（これより長いとエラー）とは違い、「だいたいこの長さにしたい」という目安です。公式は、読みやすさのために 80 を超える値は勧めない、と書いています。

Prettier 公式は、オプションを増やさない方針です。オプションが増えるほど、スタイルの議論が「どのオプションにするか」の議論に変わるだけだ、というのが理由です。

一部だけ整形しないときは、直前に // prettier-ignore のコメントを書きます。ファイルごと整形しないときは、.prettierignore に書きます（.gitignore と同じ書き方です。node_modules は、最初から対象外です）。

コミットの前に自動で整形したいときは、公式が husky と lint-staged を使う例を載せています。ESLint も使うなら、lint-staged で ESLint を Prettier より先に動かすよう、公式は書いています。この記事では流していません。

出典: Prettier 公式: Install・Prettier 公式: CLI（終了コード）・Prettier 公式: Configuration File・Prettier 公式: Options・Prettier 公式: Option Philosophy・Prettier 公式: Ignoring Code

ESLint と Prettier がぶつかるのはなぜ？ぶつからない設定は？

ぶつかる理由

Prettier の公式は、ぶつかる理由をこう説明しています。リンターには、コードの品質のルールだけでなく、スタイルのルールもあります。スタイルのルールの多くは、Prettier を使うと要らなくなります。それどころか、Prettier とぶつかることがあります。

どうぶつかるのかを、手元で確かめました。わざと、ESLint の整形ルールを2つ有効にしています（semi は「セミコロンを付けない」、quotes は「シングルクォートを使う」）。Prettier の既定は、セミコロンあり・ダブルクォートなので、逆の向きです。

// eslint.config.mjs（eslint-config-prettier はまだ無い）
import { defineConfig } from "eslint/config";
import globals from "globals";
import js from "@eslint/js";

export default defineConfig([
	{ files: ["**/*.js"], languageOptions: { globals: globals.node } },
	{ files: ["**/*.js"], plugins: { js }, extends: ["js/recommended"] },
	{ rules: { semi: ["error", "never"], quotes: ["error", "single"] } },
]);

（この節の確認は、package.json を "type": "module" にして、同じ中身を eslint.config.js に置いて流しました。）.prettierrc の中身は {} です。app.js は、次のとおりです。

const unused = 1
const user = {name:"taro"}
console.log(user.name)

Prettier で整形すると、app.js はこうなります。

const unused = 1;
const user = { name: "taro" };
console.log(user.name);

整形した直後に ESLint を流すと、使っていない変数の1件のほかに、整形のルールのエラーが4件出ました。

app.js
  1:7   error  'unused' is assigned a value but never used  no-unused-vars
  1:17  error  Extra semicolon                              semi
  2:22  error  Strings must use singlequote                 quotes
  2:30  error  Extra semicolon                              semi
  3:23  error  Extra semicolon                              semi

✖ 5 problems (5 errors, 0 warnings)
  4 errors and 0 warnings potentially fixable with the `--fix` option.

そこで npx eslint --fix app.js で直すと、セミコロンが消えて、引用符がシングルクォートになりました。すると今度は、npx prettier app.js --check が「整形されていない」と言って、終了コード 1 で落ちました。Prettier が整えたものを ESLint が戻し、ESLint が整えたものを Prettier が戻す形です。これが「ぶつかる」の正体です。

eslint-config-prettier で、ぶつかるルールを止める

Prettier の公式が勧める形は、ぶつかるルールや要らないルールを止める出来合いの設定、eslint-config-prettier を使うことです。Prettier の Install のページにも、「ESLint を使うなら eslint-config-prettier を入れる。Prettier と衝突しうる、または要らない ESLint のルールを全部止める」という趣旨の文があります。

npm i -D eslint-config-prettier

eslint.config.js では、eslint-config-prettier/flat を読み込んで、設定の配列の一番うしろに置きます。公式は「上書きしたい他の設定のあとに置く」と書いています。

import { defineConfig } from "eslint/config";
import globals from "globals";
import js from "@eslint/js";
import eslintConfigPrettier from "eslint-config-prettier/flat";

export default defineConfig([
	{ files: ["**/*.js"], languageOptions: { globals: globals.node } },
	{ files: ["**/*.js"], plugins: { js }, extends: ["js/recommended"] },
	{ rules: { semi: ["error", "never"], quotes: ["error", "single"] } },
	eslintConfigPrettier,
]);

手元で、これを足して app.js を Prettier で整形し直したあとに ESLint を流すと、semi と quotes のエラーは消え、使っていない変数の1件だけが残りました。

app.js
  1:7  error  'unused' is assigned a value but never used  no-unused-vars

✖ 1 problem (1 error, 0 warnings)

npx prettier app.js --check も、終了コード 0 で通りました。この結果は、冒頭の違いの表のとおりです。使っていない変数は、Prettier は何も言わず、ESLint だけが報告します。

eslint-config-prettier について、知っておきたいことを挙げます。

• ルールを「止める」だけです。ほかの設定と一緒に使って、初めて意味があります（README の説明）
• 止めるのは、ESLint 本体のルールだけではありません。@stylistic・@typescript-eslint・react・vue・unicorn などのプラグインのルールも止めます。バージョン 8.0.0（2021年2月21日）で設定が1つにまとまり、古い手順の "prettier/@typescript-eslint" のような名前は、案内のエラーになります（CHANGELOG の記述で、このエラーは手元では再現していません）。手元で 10.1.8 の設定を見ると、ルールは 358 個入っていて、semi・@stylistic/semi・@typescript-eslint/semi は "off" でした
• /flat が付いた入口は、10.1.1（2025年3月7日）から追加されたものです。違いは、設定に name が付くだけです。付けない "eslint-config-prettier" も flat config で使えます。手元では、どちらでも結果は同じでした。typescript-eslint の公式の例は /flat の無い形で書かれていますが、どちらも間違いではありません
• flat config では、プラグインの名前を自分で決められます。ただし、公式の名前（@typescript-eslint など）以外にすると、eslint-config-prettier はそのプラグインのルールを止められません。名前は公式のものにしておきます

落とし穴: うしろに書いたルールは、また有効になる

eslint-config-prettier は、配列の一番うしろに置くのが基本です。置いたあとに、同じルールを有効にする設定を書くと、そのルールはまた有効になります。公式も、flat config では、何が何を上書きするかを自分で決められる、と書いています。

手元で、semi と quotes を eslint-config-prettier のうしろに書くと、整形のエラーが戻りました。

export default defineConfig([
	{ files: ["**/*.js"], languageOptions: { globals: globals.node } },
	{ files: ["**/*.js"], plugins: { js }, extends: ["js/recommended"] },
	eslintConfigPrettier,
	{ rules: { semi: ["error", "never"], quotes: ["error", "single"] } },
]);

こういう取りこぼしを見つけるために、eslint-config-prettier には確かめる道具があります。

npx eslint-config-prettier app.js

うしろに書いた設定のとき、道具は次のように報告し、終了コード 2 で終わりました（公式の説明では、0 は問題なし、1 は予期しないエラー、2 はぶつかるルールがあった、です）。

The following rules are unnecessary or might conflict with Prettier:

- semi

The following rules are enabled but cannot be automatically checked. See:
https://github.com/prettier/eslint-config-prettier#special-rules

- quotes

semi はぶつかるルールとして挙げられました。quotes は、Prettier と一緒に使うときに注意が要る「特別なルール」の1つで、有効になっているけれど自動では確かめられない、と報告されました。curly・max-len なども、同じ「特別なルール」に入っています。

この道具は、2026年10月10日に ESLint 10.12.0 で動きました。ただし README は、flat config のとき、この道具は eslint/use-at-your-own-risk というものを読み込んでいて、いつ壊れてもおかしくない、と書いています。

出典: Prettier 公式: Integrating with Linters・Prettier 公式: Install（ESLint とそのほかのリンター）・eslint-config-prettier の README・eslint-config-prettier: Installation・eslint-config-prettier: プラグインの名前の注意・eslint-config-prettier: CHANGELOG・eslint-config-prettier: 確かめる道具

TypeScript で使うには？TypeScript 7 とは一緒に使える？

TypeScript のコードを ESLint で調べる

ESLint は、最初から入っている Espree というパーサー（コードを読み取る部品）を使います。このパーサーは、標準の JavaScript を読むためのものです。TypeScript のコードを ESLint で読むには、typescript-eslint というプロジェクトの @typescript-eslint/parser が要ります。ESLint の公式も、この例を挙げています。

typescript-eslint の公式の始め方は、次の2段階です。

npm install --save-dev eslint @eslint/js typescript typescript-eslint

// eslint.config.mjs
// @ts-check
import js from '@eslint/js';
import { defineConfig } from 'eslint/config';
import tseslint from 'typescript-eslint';

export default defineConfig({
  files: ['**/*.{js,ts}'],
  extends: [js.configs.recommended, tseslint.configs.recommended],
});

recommended が2つ並んでいます。前者が ESLint 本体、後者が typescript-eslint の推奨設定です。typescript-eslint の recommended は、TypeScript とぶつかる ESLint 本体のルールも止めます。

次の app.ts に、この設定で ESLint を流しました。

const unused: number = 1;
let data: any = JSON.parse("{}");
export function hello(name: string): string {
  return "hello " + name + data;
}

app.ts
  1:7   error  'unused' is assigned a value but never used      @typescript-eslint/no-unused-vars
  2:5   error  'data' is never reassigned. Use 'const' instead  prefer-const
  2:11  error  Unexpected any. Specify a different type         @typescript-eslint/no-explicit-any

✖ 3 problems (3 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

このとき入ったのは、ESLint 10.12.0・typescript-eslint 8.71.1、そして TypeScript 6.0.3 でした。上の npm install を、版を指定せずに2026年10月10日に流すと、npm 11.8.0 は TypeScript の最新（7.0.2）ではなく、typescript-eslint が対応する 6.0.3 を選びました。ほかの版の npm や、pnpm・yarn では試していません。

公式は、さらに2つの設定を案内しています。strict は、recommended に、より「意見の入った」ルールを足した設定です。stylistic は、ロジックを変えずに、書き方をそろえるルールです。ここでいう「書き方」は、空白などの整形とは別の意味です。また、型の情報を使うルール（typed linting）には recommendedTypeChecked と parserOptions.projectService: true を使います。公式は、こうしたルールは普通のルールより遅いが、ずっと強力だ、と書いています。typed linting は流していません。

TypeScript 7 とは、2026年10月10日時点で一緒に使えない

TypeScript 7 は、コンパイラを Go に移植した版です。詳しくは、TypeScript 7 の記事にまとめています。

typescript-eslint 8.71.1（2026年10月5日公開）が対応する範囲は、ESLint が ^8.57.0 || ^9.0.0 || ^10.0.0、TypeScript が >=4.8.4 <6.1.0（4.8.4 以上、6.1.0 未満）です。TypeScript 7 は範囲の外です。

TypeScript の最新（7.0.2）を入れて ESLint を動かすと、次のように止まりました（終了コード 2）。

typescript-eslint does not support TS 7.0.
Please see https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/#running-side-by-side-with-typescript-6.0 to run typescript-eslint using the TS 6 API.
See also https://github.com/typescript-eslint/typescript-eslint/issues/10940 for tracking typescript-eslint's support for TS >=7.1

typescript-eslint の公式は、対応していない TypeScript を使うとパーサーが警告を出す、と書いています。2026年10月10日に確かめた TypeScript 7.0.2 では、警告ではなく、このエラーで止まりました。ほかの対応外の版（6.1 以上の 6 系など）でどうなるかは、確かめていません。

TypeScript 6 と並べれば動く

TypeScript の公式ブログは、TypeScript 7.0 には API（ほかの道具がコンパイラを呼び出すための入口）が無いので、typescript-eslint のような道具のために、6.0 を並べて使う方法を用意した、と書いています。互換パッケージ @typescript/typescript6 を、npm の別名（エイリアス）で typescript として入れ、7 の typescript（7.0）は、@typescript/native という別名（エイリアス）を付けて入れます（その名前のパッケージが npm にあるわけではありません）。コマンドは、7 が tsc、6 が tsc6 です。

npm install --save-dev [email protected] @eslint/[email protected] [email protected] typescript@npm:@typescript/typescript6@^6.0.2 @typescript/native@npm:typescript@^7.0.2

package.json には、次のように書かれます。

"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2",

手元でこの形にすると、npx tsc -v は 7.0.2、npx tsc6 -v は 6.0.3 と出て、ESLint も typescript-eslint で動きました（上と同じ3件）。

typescript-eslint が TypeScript 7 に対応する日は、公式の資料に書かれていません。追跡用の Issue（#10940）は、2026年10月10日時点で開いたままです。2026年9月29日に、メンテナーが「TypeScript 7.1 への対応は作業中で、安定してきた」と報告しています。対応する Pull Request（#12803）は、2026年10月10日時点で下書き（draft）のまま開いています。この状況は動くので、使う前に Issue を見てください。

出典: ESLint 公式: Core Concepts（パーサー）・typescript-eslint 公式: Getting Started・typescript-eslint 公式: Typed Linting・typescript-eslint 公式: 対応する版・TypeScript 公式ブログ: Announcing TypeScript 7.0（6.0 と並べて使う）・typescript-eslint の Issue #10940・typescript-eslint の Pull Request #12803

VS Code で、保存したときに整形・修正するには？

エディタの VS Code で、ファイルを保存したときに Prettier で整形し、ESLint で直す設定を説明します。この節は、VS Code を動かして確かめていません。VS Code と、2つの拡張機能の公式の文書に書かれていることだけを書きます。

拡張機能を入れる

VS Code の「拡張機能」の画面で、名前を検索して入れます。

拡張機能	ID	版（Marketplace、2026年10月10日に確認）
ESLint	dbaeumer.vscode-eslint	3.0.34（2026年7月16日）
Prettier - Code formatter	esbenp.prettier-vscode	12.4.0（2026年3月16日）

ESLint の拡張は、開いたフォルダに入っている ESLint を使います。入っていなければ、パソコン全体（グローバル）に入れた ESLint を探します。README は、プロジェクトに入れる形を勧めています。ESLint の拡張の設定 eslint.useFlatConfig は、ESLint 10 以上では無視され、flat config だけが使われます（切れません）。

Prettier の拡張も、プロジェクトに入れた Prettier を使うのが勧められる形です。入っていなければ、拡張に同梱された 3.x を使います。Prettier の公式も、エディタが正しい版を使うように、プロジェクトごとに入れるよう書いています。設定は、プロジェクトの Prettier の設定ファイルに書くのが勧められています。.prettierrc などがあるときは、VS Code の設定（prettier. で始まるもの）は使われません。

なお、ESLint 10 の移行ガイドは、エディタ経由で ESLint を使うときは、エディタ側の Node.js の版も確かめるよう書いています。VS Code が使う Node.js の版は、確かめていません。

保存時の整形は、最初はオフ

VS Code の文書によると、整形の操作は「Format Document」（Mac は ⇧⌥F、Windows は Shift+Alt+F、Linux は Ctrl+Shift+I）です。保存したとき、入力したとき、貼り付けたときの整形は、最初はオフで、editor.formatOnSave などの設定で有効にします。Prettier の拡張の README も、保存時の整形は editor.formatOnSave の設定に従う、と書いています。そのため、拡張を入れただけでは、保存時の整形が有効になるとは限りません。

複数の整形用の拡張を入れているときに Prettier を使わせるには、既定のフォーマッターを Prettier にします。拡張の README に、この設定があります。保存時の整形は、言語ごとに有効にもできます。

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.formatOnSave": true
  }
}

（公式の例を組み合わせた形で、動かして確かめていません。）editor.defaultFormatter は、"[javascript][typescript]" のように言語をまとめては書けず、言語ごとに別々に書く、と README にあります。

プログラミングに必要なツールを紹介した記事にも、Prettier - Code formatter が出てきます。保存時に整形するには、上のような設定が要ります。

保存時に ESLint の修正を走らせる

editor.codeActionsOnSave という設定で、保存したときに ESLint の自動修正（--fix に近いもの）を走らせられます。ESLint の拡張の README の例は、次の形です。

"editor.codeActionsOnSave": {
  "source.fixAll.eslint": "explicit"
}

値は、VS Code の文書によると、"explicit"（既定。自分で保存したとき）・"always"（自動保存のときも）・"never" です。true と false は今も使えますが、いずれ非推奨になる、とあります。ここに書いた項目は、書いた順に走ります。

Prettier の拡張の README は、リンターとの組み合わせについて、整形は Prettier に任せ、リンターは整形のルールを扱わない設定にするのが勧められる形だと書いています。「整形のルールを扱わない設定」は、「ぶつからない設定」の節で説明した eslint-config-prettier のことです。保存時に Prettier を先に、ESLint をあとに走らせるなら、次のように並べます。

"editor.codeActionsOnSave": {
  "source.fixAll.prettier": "explicit",
  "source.fixAll.eslint": "explicit"
}

source.fixAll.prettier は、Prettier の拡張の 12.1.0 で入りました。この順番は、Prettier の拡張の README の言い分で、ESLint の文書には、同じ内容の文は見つかりませんでした。

出典: VS Code 公式: Formatting・VS Code 公式: Code Actions on Save・ESLint の拡張の README・ESLint の拡張: 10.0.0 以上では useFlatConfig は無視される・Prettier の拡張の README・Prettier の拡張: 既定のフォーマッター・Prettier の拡張: リンターとの組み合わせ・Prettier 公式: Editor Integration・Marketplace: ESLint・Marketplace: Prettier - Code formatter

よくある質問

eslint-config-prettier と eslint-plugin-prettier の違いは？

名前が似ていますが、別の道具です。typescript-eslint の公式は、こう説明しています。

• eslint-config-prettier: 設定です。ESLint 本体と、ほかのプラグインのルールを止めるだけ
• eslint-plugin-prettier: プラグインです。ESLint の中で Prettier を動かす

2つ目は、整形のずれを ESLint のエラーとして出します。flat config では、eslint-plugin-prettier/recommended を、配列の一番うしろに置きます。これで prettier/prettier というルールが有効になり、arrow-body-style と prefer-arrow-callback が止まり、eslint-config-prettier も入ります（最新の 5.5.6 は、ESLint 8 以上・Prettier 3 以上が要ります）。

手元で、[email protected] を、eslint-plugin-prettier/recommended だけを足した設定で動かすと、整形の差が prettier/prettier のエラーとして出て、eslint --fix で整形されました。

app.js
  1:15  error  Replace `name:"taro"}` with `·name:·"taro"·};`  prettier/prettier
  2:23  error  Insert `;`                                      prettier/prettier

✖ 2 problems (2 errors, 0 warnings)
  2 errors and 0 warnings potentially fixable with the `--fix` option.

ただし、Prettier の公式は、この種のプラグインは「たいていは勧めない」と書いています（役に立つ場面もある、とも書いています）。欠点として挙げているのは、次の3つです。エディタに赤い波線が増えて邪魔になること、Prettier を直接動かすより遅いこと、壊れうる場所が1つ増えること。公式は、いまは prettier --check . があり、たいていのエディタが Prettier に対応している、とも書いています。この記事が、「Prettier は Prettier で動かし、ESLint には eslint-config-prettier を足す」形で説明したのは、そのためです。

eslint-plugin-prettier の README は、Prettier のオプションを ESLint の設定に書くのは勧めない、と書いています。エディタの Prettier の拡張は .prettierrc を読みますが、ESLint の設定は読まないので、結果がずれることがあるからです。

出典: typescript-eslint 公式: eslint-plugin-prettier・Prettier 公式: Integrating with Linters（Notes）・eslint-plugin-prettier の README・eslint-plugin-prettier: Options

VS Code で Prettier が効かないときは？

Prettier の拡張の公式の手引きは、次の順で確かめるよう書いています（手元では確かめていません）。

1. Prettier が既定のフォーマッターになっているか
2. 出力パネルにエラーが出ていないか
3. 「Using bundled Prettier」と出ていたら、拡張は動いているが同梱の Prettier を使っています。プロジェクトに Prettier を入れる
4. .prettierignore に、そのファイルが入っていないか
5. prettier.requireConfig が true のときは、設定ファイルが無いと整形されません。設定ファイルがあるか

出典: Prettier の拡張: Troubleshooting

ESLint 9 から 10 に上げるには？9 はもう使えない？

ESLint 9 系は、2026年8月6日にサポートが終わりました。サポートが終わったのは、使えなくなったという意味ではなく、公式が保守をしなくなった、という意味です。いまサポートされているのは 10 系だけです（2026年10月10日時点）。

上げる前に確かめたいことは、公式の移行ガイドによると、次のとおりです。

• Node.js の版: 20.19.0 以上の 20 系、22.13.0 以上の 22 系、24 以上です
• .eslintrc を使っていないか: 10 では読まれません。「古い設定を移す」の節の表と道具を使います
• ファイルの中の /* eslint-env */ コメントが無いか: 10 ではエラーになります
• エディタ経由で使うときは、エディタ側の Node.js の版

公式は、9 から 10 への移行用に npx codemod @eslint/v9-to-v10 を用意していて、「出発点なので、変更は見直すこと」と書いています（流して確かめてはいません）。

出典: ESLint 公式: Version Support・ESLint 公式: v10 への移行ガイド

ESLint と Prettier の代わりになる、1つで済む道具はある？

Biome は、整形とリントなどを1つで行う道具（ツールチェーン）です。2026年10月10日時点の最新は 2.5.15 です。Biome の公式サイトは、整形が Prettier と 97% 互換だと書き、リントのルールは 2.5 で 500 を超えたと書いています。これは Biome 自身の主張で、第三者が確かめたものではありません。

ESLint と Prettier の設定から移すコマンド（biome migrate eslint --write・biome migrate prettier --write）も、公式に載っています。この記事では、Biome を動かして確かめていません。ESLint と Prettier の組み合わせと Biome のどちらを選ぶべきかを比べた資料も、見つけていません。「1つで両方をする道具もある」という紹介にとどめます。

出典: Biome 公式・Biome 公式: ESLint と Prettier からの移行

まとめ

• ESLint は、コードの中の問題を見つけて知らせる道具（リンター）。Prettier は、見た目をそろえる道具（フォーマッター）。Prettier の公式は「整形は Prettier、バグ探しはリンター」と書いている
• ESLint 自身も、整形のルールは 8.53.0 で非推奨にして、整形専用の道具（Prettier など）を勧めている。ESLint 10.12.0 でも、整形のルールは非推奨のまま残っている
• ESLint の設定ファイルは eslint.config.js。.eslintrc は v9.0.0（2024年4月）で非推奨、v10.0.0（2026年2月）で削除され、10 では読まれない。9 系のサポートは2026年8月6日に終わった
• npm init -y のあとに、import で書いた eslint.config.js を置くと、"type": "commonjs" のせいで止まる。eslint.config.mjs にするか、"type": "module" にする
• Prettier は --save-exact で版を固定して入れ、npx prettier . --write で整形、--check で確かめる
• 2つを一緒に使うときは、eslint-config-prettier を設定の一番うしろに置く。うしろに書いたルールは、また有効になる。確かめる道具 npx eslint-config-prettier がある
• 2026年10月10日時点では、typescript-eslint 8.71.1 は TypeScript 7 に対応していない。TypeScript の公式の「6 と 7 を並べる」書き方なら動いた
• VS Code の保存時の整形は最初はオフ。設定の書き方は公式の文書のとおりで、この記事では動かして確かめていない

版や対応は動くので、使う前に公式の最新の案内を見てください（2026年10月10日時点の記述です）。

参考資料

• ESLint 公式: Getting Started
• ESLint 公式: Configuration Files
• ESLint 公式: Core Concepts
• ESLint 公式: 設定の移行ガイド
• ESLint 公式: v10 への移行ガイド
• ESLint v10.0.0 のお知らせ
• ESLint v9.0.0 のお知らせ
• ESLint 公式ブログ: Flat config rollout plans
• ESLint 公式ブログ: Deprecating Formatting Rules
• ESLint 公式: Version Support
• ESLint 公式: ルール一覧
• Prettier 公式: Install
• Prettier 公式: Prettier vs. Linters
• Prettier 公式: Integrating with Linters
• Prettier 公式: Options
• eslint-config-prettier の README
• eslint-plugin-prettier の README
• typescript-eslint 公式: What About Formatting?
• typescript-eslint 公式: Getting Started
• typescript-eslint 公式: 対応する版
• TypeScript 公式ブログ: Announcing TypeScript 7.0
• VS Code 公式: Formatting
• VS Code 公式: Code Actions on Save
• ESLint の拡張の README
• Prettier の拡張の README
• Biome 公式

※この記事は、公式の資料をもとに AI（Claude）で下書きし、2026年10月10日時点の公式の資料と照らして確かめてから公開しています。誤りに気づいたらお問い合わせからお知らせください。