eslint-config-prettier: turning off the rules Prettier already handles

The double-reporting problem eslint-config-prettier exists to remove

Run Prettier and ESLint on the same file and you can get two opinions about indentation. Prettier rewrites the file; ESLint's stylistic rules, whether from a shareable config or from your own rules block, report the same lines as errors. The README describes the package as turning off "all rules that are unnecessary or might conflict with Prettier." That is the whole job. It is not a formatter, and the README says plainly that the config only turns rules off, so it only makes sense alongside some other config. If your project does not run Prettier at all, this package has nothing to disable and no reason to be in your dependency list. The audience is narrow and specific: teams that already committed to Prettier for formatting and want ESLint to keep only the non-formatting checks.

How the config disables rules, and which plugins it knows about

The package ships several entry points. The default export is the eslintrc-style config, and there is a separate flat config entry under the /flat subpath, which the README notes adds a name property to the exported object to improve the ESLint config-inspector experience. A third subpath, /prettier, also exists in package.json exports. Rule coverage is not limited to ESLint core. The README lists plugins whose rules are turned 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. The README also addresses a piece of folklore directly: guides that tell you to extend "prettier/react" are out of date, because since version 8.0.0 extending "prettier" covers all the bundled plugins. Ordering is the mechanism that makes any of this work. In eslintrc the entry goes last in the extends array; in flat config it goes after the configs you want to override. Position in the array is the override, not any special flag.

Install and first run: npm, then a flat config that actually takes effect

The README gives four package-manager variants for installation. The npm one is the shortest:

npm i -D eslint-config-prettier

For flat config, import the /flat subpath and place it after the configs you want it to override. The README's example uses a placeholder import for another shareable config:

import someConfig from "some-other-config-you-use";
import eslintConfigPrettier from "eslint-config-prettier/flat";

export default [
  someConfig,
  eslintConfigPrettier,
];

After wiring the config, run the bundled CLI helper against a file that exists in your project. The README uses this form:

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

What you should see is a report naming rules that are unnecessary or conflict with Prettier, so you can delete them from your own rules block. The README recommends running it on one file as a practical default, and notes that a fully rigorous check would mean running it on every file, because ESLint allows different rules per file through multiple configuration files and overrides.

The flat config plugin-name caveat is the sharpest edge here

In eslintrc, a plugin's rules always carry the plugin's canonical prefix. In flat config you choose the key in the plugins object, and the rule name follows that key. The README walks through an example where @typescript-eslint/eslint-plugin is registered under the short name ts, with the rule written as "ts/indent": "error". eslint-config-prettier will not turn that rule off, because it only knows the rule as @typescript-eslint/indent. The README states this outright: it cannot know what you chose to call the plugin, and the same blind spot applies to the CLI helper tool. The guidance is to stick to official plugin names, and to ask maintainers of any shared config that uses a non-standard name to switch. This is a silent failure mode. Nothing errors; you simply keep seeing formatting complaints that the config was supposed to suppress, and the checker will not flag them either.

Deprecated rules, and why the checker sometimes reports more than you expect

Some rules the config turns off are deprecated or removed from ESLint entirely. The README calls this "perfectly fine" and treats it as expected rather than a defect. If you need to omit those entries, set the ESLINT_CONFIG_PRETTIER_NO_DEPRECATED environment variable to a non-empty value. The README's example combines it with eslint-find-rules:

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

The package's own test script uses the same variable, running the suite once with it set and once with ESLINT_USE_FLAT_CONFIG=false, which is a useful signal about which ESLint modes the maintainers exercise. The limitation worth naming is scope. The config disables rules; it does not detect that Prettier and ESLint disagree about a rule you wrote yourself under a custom name, and it does not touch rules defined in your own rules block for eslintrc, because ESLint lets you override configs you extend. That is exactly why the CLI helper exists as a separate step rather than as part of the config.

eslint-config-prettier versus eslint-plugin-prettier

These two are frequently confused, and the README points readers toward eslint-plugin-prettier's recommended config when they are using that plugin. The difference in approach is structural. eslint-config-prettier is a set of rule switches set to off; it configures nothing to run and produces no diagnostics of its own. eslint-plugin-prettier runs Prettier as an ESLint rule, so formatting differences surface as ESLint errors. Choosing between them is a question of where you want formatting failures to appear. If you want one tool reporting one class of problem, the config-only route keeps ESLint focused on code correctness. If you want Prettier's output enforced through the same exit code as your lint step, the plugin route does that, and the config package is then the thing that stops the two from arguing. The README's framing supports running the config alongside a shareable config of your choice, not instead of one.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-13. The most recent release listed is v10.1.8 from 2025-07-18, with v10.1.5 and v10.1.4 before it in May 2025. The project ships changesets (.changeset/ is a top-level directory) and uses yarn 4.18.0 as its package manager, so releases are prepared through that workflow. The licence is MIT, which permits commercial use and modification; that is a statement about the licence text, not legal advice, and anyone redistributing a modified build should read the LICENSE file in the repository. Upgrade cost is mostly about your ESLint mode rather than the package version. Moving from eslintrc to flat config changes which entry point you import and where the config sits in the array, and it introduces the plugin-name caveat described above. The version 8.0.0 change is the one that removed the need for per-plugin extend strings, so configs still carrying "prettier/react" are working against documentation that no longer applies.

Editorial conclusion

Adopt eslint-config-prettier if you already run Prettier and want ESLint to stop reporting formatting rules; skip it if Prettier is not part of your toolchain, since the config only turns rules off and does nothing on its own. Before rolling it out, run npx eslint-config-prettier on one real entry file, and check whether your flat config renames any plugin, because a renamed @typescript-eslint plugin will not be matched by the config or the checker.

Frequently asked questions

Official sources

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