eslint-config-prettier

eslint-config-prettier is a shareable ESLint configuration that turns off every core and plugin rule known to conflict with, or be made redundant by, Prettier’s own formatting. It doesn’t add any style rules of its own — it only disables the ones that would otherwise fight with Prettier, so teams can keep using their favorite ESLint config for correctness and code-quality rules while letting Prettier own formatting entirely.

Beyond the rule-disabling config itself, the package ships a small CLI helper (npx eslint-config-prettier <file>) that inspects a project’s fully-resolved ESLint configuration and reports any rules that are still enabled despite conflicting with Prettier, categorizing them by severity (definite conflicts, option-dependent conflicts, rules that need manual judgment, and rules that are risky specifically with eslint-plugin-prettier’s —fix). It supports both legacy eslintrc and modern flat config via dedicated entry points.

What You Get

• A single rules object mapping every known Prettier-conflicting rule (core ESLint plus @babel, @stylistic, @typescript-eslint, flowtype, react, standard, unicorn, and vue plugins) to “off”
• Separate /flat and /prettier subpath exports so both eslintrc-style extends arrays and ESLint 9’s flat eslint.config.js arrays get a native, zero-boilerplate integration point
• A bundled eslint-config-prettier CLI that resolves your project’s effective config per file and flags any rule still enabled that conflicts with Prettier, with docs links per category
• Explicit “special rules” handling (e.g. curly, @stylistic/max-len) that are conditionally safe with Prettier, validated against their actual option values rather than being blanket-disabled
• An ESLINT_CONFIG_PRETTIER_NO_DEPRECATED environment flag to exclude deprecated/removed ESLint rules from the disabled set for teams on newer ESLint versions

Common Use Cases

• Appending “prettier” last in an eslintrc extends array (or importing eslint-config-prettier/flat last in a flat config array) to neutralize formatting-rule conflicts from whatever base config a project already uses
• Running npx eslint-config-prettier index.js in CI or pre-commit to catch cases where a project’s own custom rules re-enable something Prettier will fight over
• Migrating an eslintrc project to ESLint 9’s flat config format while keeping the same Prettier-compatibility guarantees via the /flat export
• Auditing multi-config monorepos (overrides per file type) by passing several representative files to the CLI helper at once

Under The Hood

Architecture

The entire package is a static data table: index.js exports a single rules object mapping every known Prettier-conflicting rule name to "off" (or a sentinel 0 for a small set of “special” rules that need option-level judgment, tracked separately from the always-off set). flat.js and prettier.js are thin re-export shims that adapt the same table for ESLint 9’s flat-config consumers and for cross-checking against eslint-plugin-prettier’s own rules, respectively. The only executable logic lives in bin/cli.js, which resolves a target file’s fully-merged ESLint config (via ESLint/FlatESLint.calculateConfigForFile), diffs the enabled rules against the disabled-rules table using bin/validators.js for option-aware special-rule checks, and prints categorized conflict reports. There is no build step and almost no state — the blast radius of a change is limited to keeping the rules table and its validators in sync with upstream plugin releases.

Tech Stack

Plain CommonJS Node.js with no runtime dependencies beyond a peerDependency on eslint>=7.0.0; package.json’s exports map exposes ., ./flat, and ./prettier subpaths for the different consumption modes. Tooling is entirely dev-time: Jest for tests, ESLint/Prettier/TypeScript for dogfooding its own code style, hand-written .d.ts files for type consumers, Yarn Berry 4.x with patch-package to patch three upstream plugins (babel, flowtype, standard), Changesets for release/versioning, and GitHub Actions across five workflows (test, check, autofix, release, pkg-pr-new) for CI.

Code Quality

test/rules.test.js dynamically generates a throwaway test-config/ directory that flips every disabled rule to "warn", then lints a large fixture tree (test-lint/) covering every supported plugin’s rule surface to confirm ESLint never errors on an unknown or removed rule. Separate suites (cli.test.js, validators.test.js) cover the CLI’s diagnostic output and the special-rule option validators individually. CI runs Prettier’s own check, ESLint, and the Jest suite on every push. The package itself is untyped JavaScript with hand-authored .d.ts declarations rather than being written in TypeScript, but test coverage for a rules-only config package is unusually thorough.

API Design Integration is a single line — "prettier" in an eslintrc extends array, or an eslintConfigPrettier import placed last in a flat-config array — with no options to configure and dedicated subpath exports so eslintrc and flat-config users each get a natural entry point. The bundled npx eslint-config-prettier <file> CLI turns “did I misconfigure this” from a silent unknown into categorized, actionable output with docs links per category, which is a notably strong developer-experience addition for a package that is otherwise just a static rules table.