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](https://prettier.io/docs/integrating-with-linters): > [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](https://github.com/prettier/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: ```bash # 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): ```js import eslintConfigPrettier from "eslint-config-prettier"; export default [ // ...your other configs eslintConfigPrettier, ]; ``` Then create your `.prettierrc`: ```json { "semi": true, "singleQuote": true, "trailingComma": "all", "printWidth": 80 } ``` Now run them separately: ```bash # 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](https://github.com/lint-staged/lint-staged)): ```json { "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.