The prettier ESLint rule disables two of ESLint's own rules

The plugin says outright when it is the wrong tool

The opening of the README sets a boundary that most plugins leave vague. This one runs Prettier as an ESLint rule and reports differences as individual ESLint issues, and then adds that if your desired formatting does not match Prettier's output, you should use a different tool such as prettier-eslint instead. That is an unusual thing for a package to say about itself, and it decides the audience before any configuration appears. The same paragraph pushes a second prerequisite: read the page on integrating with linters before installing. So the intended user is someone who has already decided Prettier's output is the output they want, and the plugin's job is to make a formatter's opinion arrive inside the lint pipeline rather than in a separate tool.

Installation is two commands and an exact prettier

The install step is deliberately split. One command installs the plugin together with the config package, and a second installs Prettier itself with an exact-version flag:

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

The file then emphasises in bold that the plugin does not install Prettier or ESLint for you and that you must install these yourself, which is why the second command exists at all. Pinning Prettier exactly is the point: the plugin compares your source against whatever Prettier version is present, so a floating Prettier changes what the linter reports. That reasoning is repeated in the surrounding text, which says the plugin works best when all other ESLint rules about code formatting are disabled and only rules that detect potential bugs stay on, because any active rule that disagrees with Prettier about formatting makes lint errors impossible to avoid.

The peer range excludes eslint-config-prettier 10.0.x

The package manifest states its support window as peer dependencies, and one of the four ranges is not a simple floor. eslint is required at >=8.0.0, prettier at >=3.0.0, @types/eslint at >=8.0.0, and eslint-config-prettier at >= 7.0.0 <10.0.0 || >=10.1.0. That expression has a hole in it on purpose: the 10.0.x line is excluded while 7.x, 8.x, 9.x and everything from 10.1.0 upward are accepted, so a team pinned to 10.0 cannot install the plugin at all. The declared engine range is separate again, node ^14.18.0 || >=16.0.0, while the repository itself builds with yarn 4.18.1 as its packageManager. The manifest version, 5.5.6, matches the newest published release, so what npm installs is what the tag v5.5.6 points at.

The recommended config has to be last in the array

Both configuration styles carry the same instruction, and the reason is ordering rather than syntax. The plugin ships a recommended config that wires up the rule and the conflicting-rules config together, and it has to be added as the last item so that eslint-config-prettier gets the opportunity to override everything before it. The legacy form:

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

and the flat form:

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

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

Load it first and the formatter rules come back, and the disagreement between them and Prettier is exactly what the next section is about. One inconsistency is worth noting in that flat sample: it uses require and module.exports, while the repository's own configuration in the tree is eslint.config.mjs alongside a .remarkrc.mjs and a .yarnrc.yml, so the example a reader copies is written in a different module system from the one the project uses itself.

arrow-body-style and prefer-arrow-callback can produce invalid code

Two of ESLint's core rules are switched off by the recommended config, and the file explains why in its own section. Using arrow-body-style or prefer-arrow-callback together with the prettier/prettier rule can, in some cases, end up with invalid code because of a bug in ESLint's autofix, tracked as issue 65. The autofixer applies both rules' edits to the same source and the combination can drop a closing parenthesis, leaving a file that does not parse. The plugin's position is that you can keep the rules if you want, because the bug does not occur all the time, but you then have to keep in mind that you might end up with invalid code where you manually have to insert a missing closing parenthesis to get going again. For an existing unformatted codebase, the advice is to switch the prettier/prettier rule off temporarily and run eslint --fix and prettier --write separately.

Passing Prettier options through ESLint works and is discouraged

The options section opens with a warning before it lists anything. It is possible to pass options to Prettier through your ESLint configuration file, and the file says not to, because editor extensions such as prettier-atom and prettier-vscode will read .prettierrc but will not read settings from ESLint, which can lead to an inconsistent experience. The first option is an object of Prettier options passed through, for example singleQuote and parser set to flow:

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

Underneath it sits the line that explains why the duplication is tempting in the first place: this option will merge and override any config set with .prettierrc files. The plugin therefore works, and the same configuration is silently applied twice in two places, once for the editor and once for the lint run.

The sample output reports the double semicolon in its own fixture

The sample at the top of the README is a real ESLint run, taken from the nuclide codebase, and it is worth reading closely because the file it lints contains the defect being reported. The command behind it is ./node_modules/.bin/eslint --format codeframe run against a file under pkg/commons-atom. The output carries two errors from the same rule:

error: Insert `,` (prettier/prettier) at pkg/commons-atom/ActiveEditorRegistry.js:22:25:
  20 | import {
  21 |   observeActiveEditorsDebounced,
> 22 |   editorChangesDebounced
     |                         ^
  23 | } from './debounced';;

The first error wants a comma after editorChangesDebounced. The second, later in the output, deletes a semicolon on the line that already ends with two of them, `} from './debounced';;`. So the sample demonstrates the plugin's central behaviour, one issue per formatting difference with a caret pointing at the exact column, using a file whose own sloppiness is the input. Each difference becomes a separate lint message rather than one report per file.

The project lints itself with ten warnings allowed

The scripts in the manifest show how the maintainers work on the plugin. check runs prettier --check on the whole tree and then the lint task, format runs prettier --write followed by eslint with the fix flag, and test runs the lint task and then mocha. The lint task fans out over two children with run-p, one being eslint over the tree with a cache and --max-warnings 10, the other being tsc. Ten warnings is a real budget rather than zero, so the repository that ships a formatting rule tolerates a handful of its own lint warnings. The prepare script runs patch-package, simple-git-hooks and a deduplication step, and a patches directory sits at the root, meaning dependencies are patched at install time rather than vendored. Release runs check, mocha, clean-pkg-json and changeset publish, backed by a .changeset directory, and the published file list has five entries, one of which, worker.mjs, is not explained anywhere in the README.

Editorial conclusion

This plugin suits a codebase already committed to Prettier's output, because that agreement is the whole basis of the rule. Anyone who wants formatting that differs from Prettier should follow the project's own advice and use prettier-eslint instead, since a rule that fights the formatter produces lint errors nobody can resolve. Before adopting it, check three things: that every other formatting rule is off through eslint-config-prettier, that the recommended config really is last in your array, and whether you accept a peer range that excludes eslint-config-prettier 10.0.x.

Frequently asked questions

Official sources

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