Stop Running Prettier Through ESLint — Here's Why Standalone Is Better

If you've set up a JavaScript project in the last few years, there's a good chance you're running Prettier through eslint-plugin-prettier. It was the go-to approach for a while — one tool, one command, one unified set of squiggly red lines in your editor. Simple, right?

Here's the thing: the Prettier team themselves recommend against it. And once you understand why, you'll probably want to change your setup too.

Prettier Formats Way More Than JavaScript

ESLint is a JavaScript (and TypeScript) tool. That's its world. When you run Prettier as an ESLint plugin, Prettier is confined to that world — it only gets invoked on files that ESLint processes.

But Prettier natively supports a much broader set of languages:

• CSS, Less, and SCSS
• HTML
• JSON
• YAML
• Markdown (including MDX)
• GraphQL
• Vue and Angular templates
• Handlebars

That package.json with inconsistent indentation? The .yaml config where someone mixed tabs and spaces? The CSS file with wildly different formatting conventions? ESLint never touches those. If Prettier only runs as an ESLint plugin, those files stay messy.

When you run Prettier standalone — via CLI, editor integration, or a pre-commit hook — a single prettier --check . or prettier --write . will catch formatting inconsistencies across all of these file types in your project, not just the ones ESLint knows about.

This is especially impactful in real-world projects. Think about how many non-JS files live in a typical repository: CI configs in YAML, style sheets, JSON data fixtures, Markdown documentation. Formatting consistency across all of them matters, and standalone Prettier gives you that for free.

It's Faster

This isn't just anecdotal — it's documented by the Prettier team on their official integration guide:

[Prettier plugins run inside linters] are slower than running Prettier directly.

Now, to be clear — both approaches parse your JS/TS files twice. Whether Prettier runs as a plugin or standalone, ESLint parses the file and Prettier parses the file. That part is the same.

The performance difference comes from the integration overhead. When Prettier runs as an ESLint plugin, there's an entire middle layer doing extra work for every file: it runs Prettier, diffs the formatted output against the original, then converts every formatting difference into an ESLint diagnostic object complete with line numbers, column offsets, and fix ranges. ESLint then processes all of those diagnostics through its reporting and auto-fix pipeline. That's a lot of machinery just to change a semicolon.

Standalone Prettier skips all of that. It parses, formats, writes. No diffing, no diagnostic generation, no round-tripping through a linter's fix system. On a large codebase or in CI, that overhead adds up.

The Red Squiggly Problem

There's a subtler UX argument the Prettier docs also make: when Prettier runs as a linter rule, every formatting issue shows up as a lint error. Your editor fills with red and yellow underlines for things like trailing commas and bracket spacing — things that Prettier will auto-fix on save anyway.

The whole point of Prettier is to stop thinking about formatting. You write code however you want, hit save, and it snaps into place. Treating formatting deviations as lint errors defeats that purpose. It adds cognitive noise instead of removing it.

With standalone Prettier, formatting happens silently via your editor's format-on-save or a pre-commit hook. The only time you hear from Prettier is when you explicitly run --check in CI — and that's just a pass/fail gate, not a wall of warnings in your editor.

The Recommended Setup

The Prettier docs lay out a clean separation of concerns:

Prettier handles formatting: indentation, line length, semicolons, quotes, trailing commas — the stuff that doesn't affect how your code runs.

ESLint handles code quality: unused variables, unreachable code, implicit globals, potential bugs — the stuff that does matter for correctness.

To prevent them from fighting, install eslint-config-prettier. It disables all ESLint rules that would conflict with Prettier, so the two tools stay in their lanes.

A typical setup looks like this:

# Install both
npm install --save-dev prettier eslint eslint-config-prettier

Add prettier to the end of your ESLint config's extends array (Flat Config shown):

import eslintConfigPrettier from "eslint-config-prettier";

export default [
  // ...your other configs
  eslintConfigPrettier,
];

Then create your .prettierrc:

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 80
}

Now run them separately:

# Check formatting across your ENTIRE project
npx prettier --check .

# Auto-fix formatting
npx prettier --write .

# Lint for code quality
npx eslint .

Or better yet, add both to your CI pipeline and a pre-commit hook (with lint-staged):

{
  "lint-staged": {
    "*": "prettier --write --ignore-unknown",
    "*.{js,ts,jsx,tsx}": "eslint --fix"
  }
}

Notice the * glob for Prettier — it runs on everything, while ESLint is scoped to JS/TS files. That's the whole point.

TL;DR

	Prettier via ESLint Plugin	Prettier Standalone
File coverage	Only JS/TS (whatever ESLint processes)	CSS, JSON, YAML, Markdown, HTML, GraphQL, and more
Speed	Slower (double parsing)	Faster (direct formatting)
Editor noise	Red squiggly lines for formatting	Silent format-on-save
Recommended by Prettier	No	Yes

If you're still running eslint-plugin-prettier, consider pulling Prettier out and letting it run on its own. You'll get broader coverage, faster runs, and a quieter editor. And you'll be following the approach the Prettier team actually recommends.