eslint-config-prettier only turns rules off, and it ships a third export path

Three export paths in the manifest, two of them explained anywhere

The `exports` map publishes three conditions. `.` resolves to `index.js` with `index.d.ts` for types, `./flat` resolves to `flat.js` with `flat.d.ts`, and `./prettier` resolves to `prettier.js` with `prettier.d.ts`, with `./package.json` exposed alongside. The `files` array lists exactly those artefacts plus the `bin` directory, seven entries in total.

The README's installation steps cover two of the three. The legacy route is `"prettier"` added to the `extends` array of an `.eslintrc.*` file, and the flat route is `eslint-config-prettier/flat` imported into the configuration array. The `eslint-config-prettier/prettier` subpath exists in the manifest and ships a type declaration and a source file.

One more detail about the flat entry: a comment in the flat config example notes that the `/flat` suffix differs from the default entry because the flat version adds a `name` property to the exported object, which the text credits to improving the experience in a config inspector. So the two documented entries are not the same object under two names.

It only turns rules off, so where you put it decides what it can reach

The stated scope is narrow on purpose. This config turns rules off and nothing else, which means it only makes sense alongside some other config, and its position in that config is the whole mechanism.

Under eslintrc the limit is imposed by ESLint. A rule set in a config you extend can be disabled by a later config, but a rule written in your own `rules` section cannot be touched by anything you extend, because your own rules win. That is why the install step says to put `"prettier"` last, and why the CLI helper reports a conflicting `"indent"` rule as something for you to delete rather than something it can override.

Flat config removes that constraint and hands you the ordering instead. The example that fixes the same conflict simply moves `eslintConfigPrettier` below the object carrying `indent: "error"`:

export default [
  someConfig,
  {
    rules: {
      indent: "error",
    },
  },
  eslintConfigPrettier, // eslint-config-prettier last
];

The text is candid that this reads badly, since the config appears to enable a rule it actually disables, and it points at the other answer: keep your rules after it and let the helper find the conflicts so you can delete them.

You name the plugin in flat config, so a renamed plugin keeps its indent rule

The flat config caveat is the sharpest edge in the package. Under eslintrc a plugin key is always written the same way, so the config can name the rule it disables. Under flat config you choose the key yourself when you register the plugin.

If you register `@typescript-eslint/eslint-plugin` under the name `ts`, then eslint-config-prettier will not turn off `ts/indent`, because it only turns off `@typescript-eslint/indent` and cannot know what you called the plugin. The example registering the plugin under a short name is annotated with a warning not to do it, and the same blind spot applies to the CLI helper tool, which reports on the names it knows.

The instruction that follows is short. Stick to the official plugin names, and if a shared config uses a non-standard one, ask its authors to change it. So the constraint is not that flat config is unsupported, it is that the name you type has to be the name the rule was published under.

The test script runs the whole suite three times over

One script encodes the compatibility matrix:

"test": "yarn test:prettier && ESLINT_CONFIG_PRETTIER_NO_DEPRECATED=true yarn test:with-env && ESLINT_USE_FLAT_CONFIG=false yarn test:with-env",

Three passes, each turning on a different axis. The first runs `test:prettier`. The second sets `ESLINT_CONFIG_PRETTIER_NO_DEPRECATED` so the generated config omits deprecated and removed rules. The third sets `ESLINT_USE_FLAT_CONFIG=false`, which runs the same tests against the legacy eslintrc path instead of flat config.

The environment variable in the middle is a documented feature, not only a test knob. Setting it to a non-empty value makes the package leave out rules that ESLint has deprecated or dropped entirely, which is otherwise harmless, since the config disabling a rule that no longer exists changes nothing. The example given for it pairs the variable with a rule finder:

env ESLINT_CONFIG_PRETTIER_NO_DEPRECATED=true npx eslint-find-rules --deprecated index.js

There is also a matching script that calls the shipped binary directly, `node ./bin/cli.js index.js`, and a second, `test:cli-sanity-warning`, that passes two files, `react.js` and `./bin/cli.js`.

The prepare script ends in || exit 0, so a failed patch does not fail the install

Two lifecycle details sit in the manifest. The `prepare` script runs `patch-package` and then `yarn-berry-deduplicate`, and the whole expression ends with `|| exit 0`. Whatever those two steps do, a non-zero exit from either is discarded, which makes `prepare` a best-effort hook rather than a gate. The `patches/` directory at the repository root is where the patched dependencies live, so the patch step is expected to do real work on a normal install.

The `release` script is `clean-pkg-json && changeset publish`, and a `.changeset/` directory sits at the root, so a version bump is recorded as a changeset rather than edited into the manifest. The `format` script is `prettier --write .`, and `.prettierrc.json` plus `.prettierignore` hold the formatting configuration for the project that disables those rules, which is the arrangement you would expect.

Tooling is pinned through Yarn Berry: `packageManager` is `[email protected]`, and `.yarn/` and `.yarnrc.yml` are committed alongside `yarn.lock`. A `.renovaterc` handles dependency updates, and the four install commands the README offers cover npm, yarn, pnpm and bun.

The CLI helper reports conflicts it has no way to fix

The package ships a binary, `bin/cli.js`, exposed as the `eslint-config-prettier` command, and the documented invocation is a single file:

npx eslint-config-prettier path/to/main.js

Several files can be passed when your setup needs it, and the reason given is ESLint's own granularity: in theory the tool has to run over every file to be certain, because ESLint supports different rules for different files, but in practice the rules are usually the same everywhere, so one file is good enough. Multiple configuration files or overrides are the case that justifies passing more:

npx eslint-config-prettier index.js test/index.js legacy/main.js

The exit code list records `0` for no problems found and `1` for an unexpected error.

What the tool does is report. Under eslintrc it cannot remove a conflicting rule from your own `rules` section, and under a renamed flat config plugin it does not recognise the rule name at all.

One extend covers nine plugins, and the alternative approach is a different package

The plugin list is the part of the config that does the most work quietly. Rules from nine plugin rule sets are switched off automatically: `@babel/eslint-plugin`, `@stylistic/eslint-plugin`, `@typescript-eslint/eslint-plugin`, `eslint-plugin-babel`, `eslint-plugin-flowtype`, `eslint-plugin-react`, `eslint-plugin-standard`, `eslint-plugin-unicorn` and `eslint-plugin-vue`.

A note heads off a common mistake. Guides online still tell people to extend extra entries such as `"prettier/react"`, and since version 8.0.0 that has been unnecessary: extending `"prettier"` is enough, plugins included. So a config file carrying several `prettier/` entries is carrying history rather than function.

The package also names its own alternative. If you use `eslint-plugin-prettier`, which runs Prettier as an ESLint rule rather than disabling the rules that overlap it, the text points you at that plugin's own recommended config instead. The package description itself is the same sentence as the opening line, that it turns off all rules that are unnecessary or might conflict with Prettier, and the install line is a single dev dependency:

npm i -D eslint-config-prettier
yarn add -D eslint-config-prettier
pnpm add -D eslint-config-prettier
bun add -D eslint-config-prettier

The manifest declares `"type": "commonjs"`, MIT licensing, funding through Open Collective, and a single maintainer entry alongside the original author.

Editorial conclusion

Take this config when a shareable config and Prettier disagree about formatting, and put it last, because that ordering is the entire mechanism: it disables rules in configs it extends, never in a rules block you wrote yourself. Three things to check before you wire it in. The package is CommonJS and exposes a third subpath, `eslint-config-prettier/prettier`, so read `prettier.d.ts` before assuming you need it. Under flat config the plugin name is yours to choose, and the config can only switch off rules under the official names, so keep them. And run the bundled CLI helper on one file before you trust the setup, because it reports conflicts it cannot fix for you.

Frequently asked questions

Official sources

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