eslint-plugin-prettier: running Prettier as an ESLint rule

What eslint-plugin-prettier actually does

Prettier formats code. ESLint finds problems. Normally they are two commands, two exit codes, and two places to look when CI goes red. This plugin collapses the formatting half into the lint half: it runs Prettier as an ESLint rule named `prettier/prettier` and reports each difference as an individual ESLint issue, with file, line, column and a code frame. The README's sample output shows exactly that shape: an `Insert ,` error and a `Delete ;` error, each attributed to `(prettier/prettier)` at a specific position, followed by `2 errors found.`

The audience is teams that already treat ESLint as their gate. If a formatting drift should stop a merge, and you would rather not wire a second check into the pipeline, this is the mechanism. It is not for people who want Prettier to run on save and never appear in lint output; for them the plugin adds noise, because every unformatted line becomes an error rather than being silently rewritten.

One boundary is stated plainly in the README: if your desired formatting does not match Prettier's output, use a different tool such as `prettier-eslint` instead. The plugin does not negotiate. Prettier decides, and ESLint reports.

How the rule, the config and the worker fit together

The package is small on purpose. The published `files` list is four entry points plus a worker: `eslint-plugin-prettier.js`, `eslint-plugin-prettier.d.ts`, `recommended.js`, `recommended.d.ts` and `worker.mjs`. The main module registers the rule; `recommended.js` is the shared config that both the legacy and flat setups point at.

The recommended config does three things, per the README. It enables the `prettier/prettier` rule. It disables `arrow-body-style` and `prefer-arrow-callback`. And it turns on `eslint-config-prettier`, which switches off ESLint rules that conflict with Prettier. That third item is the architectural point: the plugin cannot make a disagreeing ESLint rule agree with Prettier, so it removes the disagreement by disabling the other rule. The README says this directly: if another active ESLint rule disagrees with Prettier about formatting, it will be impossible to avoid lint errors.

Order matters because of that. In legacy config, `plugin:prettier/recommended` goes last in `extends`. In flat config, the imported object goes last in the array. Both are described as giving `eslint-config-prettier` the chance to override other configs. Put it first and the overrides land before the configs they are meant to override.

There is also a `worker.mjs` in the shipped files, which suggests formatting work is offloaded, but the README does not describe a worker model or any threading behaviour, so treat that as an implementation detail rather than a documented feature.

Installing it and getting a first error out of it

The README gives the install as two commands, and it is emphatic that the plugin installs neither Prettier nor ESLint for you:

npm install --save-dev eslint-plugin-prettier eslint-config-prettier
npm install --save-dev --save-exact prettier

The `--save-exact` on Prettier is deliberate. Formatting output changes between Prettier versions, so a floating range can turn a green build red without anyone editing code.

For flat config, the README's example imports the recommended config and places it last:

const eslintPluginPrettierRecommended = require('eslint-plugin-prettier/recommended');

module.exports = [
  // Any other config imports go at the top
  eslintPluginPrettierRecommended,
];

After that, running ESLint over a file with a stray comma or semicolon should produce output shaped like the README's sample: an error per difference, tagged `(prettier/prettier)`, with a code frame and a position. If you get nothing, the usual cause is that another config was appended after the recommended one and re-enabled a conflicting rule.

For the older `.eslintrc*` format, the README gives a one-key JSON file instead:

{
  "extends": ["plugin:prettier/recommended"]
}

Either way, the peer ranges in package.json are the real gate: `eslint >=8.0.0`, `prettier >=3.0.0`, and `eslint-config-prettier` at `>= 7.0.0 <10.0.0 || >=10.1.0`. The `@types/eslint` and `eslint-config-prettier` peers are marked optional.

The arrow-body-style autofix bug, and why the config disables two rules

This is the most concrete limitation the project documents, and it is not cosmetic. If `arrow-body-style` or `prefer-arrow-callback` run alongside `prettier/prettier`, ESLint's autofix can in some cases produce invalid code. The README traces it to a bug in ESLint's autofix and links issue #65.

The recommended config disables both rules for that reason. You can re-enable them, and the README concedes the bug does not occur all the time, but the failure mode is a missing closing parenthesis that you have to insert by hand before the file parses again. That is a bad trade in an automated pipeline, and it is why the plugin reaches into rule configuration rather than only adding one rule of its own.

The second documented failure mode is Svelte. With `eslint-plugin-svelte3`, the plugin will simply ignore the text passed to it, because that text has been modified by the time the rule sees it. The README recommends `eslint-plugin-svelte` instead, which uses a real `eslint-svelte-parser` rather than hacking the text. If you stay on `svelte3`, formatting Svelte files means running `prettier --write *.svelte` yourself. Silent non-enforcement is worse than a loud error, and that is what this path gives you.

Passing Prettier options through ESLint, and why the README argues against it

The `prettier/prettier` rule accepts an options object as its first option, mirroring Prettier's own option names. The README's example puts it inline in JSON config:

{
  "prettier/prettier": [
    "error",
    {
      "singleQuote": true
    }
  ]
}

The README then argues against doing this. Editor extensions such as `prettier-atom` and `prettier-vscode` read `.prettierrc` but will not read settings from ESLint, so options declared in the ESLint config can produce a different result in the editor than in CI. Two sources of truth for the same formatter is a configuration smell, and the project itself flags it.

The practical consequence: keep formatting options in `.prettierrc` and let the rule read them, and use the inline object only when you have a reason to override for a specific file set. The repository keeps a `.prettierrc` at its root, which is consistent with that advice for its own codebase.

Where it is the wrong tool, and what to use instead

The clearest wrong-tool case is a large body of previously unformatted code. The README's own guidance is to temporarily disable the `prettier/prettier` rule and run `eslint --fix` and `prettier --write` separately. Turning on the rule across a legacy repository produces thousands of errors that are all the same class of problem, and the two tools running independently handle that migration better.

The second case is teams that want formatting decoupled from linting entirely. If your CI already runs `prettier --check .` and you are happy with a second, faster step, this plugin buys you nothing except a slower lint run and a rule that has to fight other rules. The README's own reference to Prettier's Integrating with linters page exists because that decision is not automatic.

The alternative worth naming here is `eslint-config-prettier` on its own, without this plugin. It is a different approach, not a smaller version of the same one: it does not run Prettier at all, it only switches off ESLint rules that conflict with Prettier. You keep `prettier --check` as a separate command and lose nothing in correctness. The plugin's install command pulls in both packages, so the split is easy to miss; the recommended config enables `eslint-config-prettier` for you, which means you can drop the plugin and keep most of the setup intact.

Maintenance, licence and what a version bump costs

The repository is not archived, and the last push was on 2026-09-01. Releases are infrequent and small: v5.5.4 on 2025-08-06, v5.5.5 on 2026-01-14, v5.5.6 on 2026-05-28. That cadence fits a thin adapter: the interesting changes happen in Prettier and ESLint, and this package mostly tracks them.

The licence is MIT, stated in package.json and in `LICENSE.md`. That is permissive and imposes no obligation beyond keeping the notice, but the plugin's usefulness depends on two other projects with their own licences and release schedules, so a licence review that stops at this package tells you little.

Upgrade cost concentrates in the peer ranges. `prettier >=3.0.0` and `eslint >=8.0.0` are the floors, and `eslint-config-prettier` has a gap in its accepted range (`<10.0.0 || >=10.1.0`), which means certain versions fall outside it. The plugin's own version number is rarely the thing that breaks you; the Prettier version is, because formatting output changes and `--save-exact` exists precisely to pin that down.

Editorial conclusion

Adopt it if you already run ESLint in CI and want formatting failures to fail the same run, with `eslint-config-prettier` loaded last so nothing fights Prettier. Skip it if you want formatting to stay a separate, faster step, or if your codebase is mid-migration: the README warns that fixing large amounts of unformatted code is better done by temporarily disabling the `prettier/prettier` rule and running `eslint --fix` and `prettier --write` separately. Before rolling it out, check the peer ranges in package.json against your installed `eslint`, `prettier` and `eslint-config-prettier` versions, and confirm whether your editor extension reads `.prettierrc` rather than ESLint settings.

Frequently asked questions

Official sources

1. License: MIT
2. prettier/eslint-plugin-prettier on GitHub
3. Project website
4. README
5. Releases