eslint-plugin-prettier

eslint-plugin-prettier integrates Prettier directly into ESLint’s rule engine, reporting any formatting difference between your source and Prettier’s expected output as a standard ESLint prettier/prettier violation — insertions, deletions, and replacements are all surfaced with precise line/column locations and can be auto-fixed via eslint --fix.

Rather than reimplementing formatting logic, the plugin lazily loads Prettier through a synckit-backed worker so a single ESLint rule visitor can call Prettier’s promise-based API synchronously, and it ships ready-made recommended configs for both legacy .eslintrc and flat eslint.config.js setups that also enable eslint-config-prettier to silence conflicting style rules.

What You Get

• A prettier/prettier ESLint rule that reports every formatting difference as an autofixable lint error
• Ready-made recommended configs for both legacy .eslintrc and flat eslint.config.js setups
• Automatic disabling of conflicting ESLint formatting rules via bundled eslint-config-prettier integration
• Support for virtual files from other ESLint processors (Markdown, HTML, GraphQL, Vue, Svelte) without double-formatting

Common Use Cases

• Enforcing consistent code formatting across a team without a separate Prettier CI step
• Auto-fixing formatting violations during eslint --fix or on save in an editor
• Migrating a codebase from format-related ESLint rules to Prettier-driven formatting
• Catching formatting drift in pull requests via a single eslint check

Under The Hood

Architecture

Single-file plugin (eslint-plugin-prettier.js) exports one ESLint rule that hooks the top-level AST node type, lazily requiring synckit’s createSyncFn against a separate worker.mjs script to bridge Prettier’s promise-based API into ESLint’s synchronous rule visitor; the worker resolves .prettierrc/.editorconfig via prettier.resolveConfig, infers a parser via prettier.getFileInfo, and formats via prettier.format(), returning the formatted string across the process boundary. Differences between source and formatted output are computed with prettier-linter-helpers’s generateDifferences and reported as individual ESLint issues with precise fix ranges. A recommended.js/recommended.d.ts pair composes the plugin with eslint-config-prettier’s rule-disabling config for flat-config consumers, while legacy .eslintrc consumers get an equivalent configs.recommended entry inside the plugin object itself. This is about as flat and single-purpose an architecture as an ESLint plugin can have — no internal layering beyond the worker-process split needed for the sync/async bridge.

Tech Stack

Plain CommonJS module for the main plugin entry, ESM worker invoked via synckit, with runtime dependencies limited to prettier-linter-helpers (diff/invisible-character formatting) and synckit (sync-over-async worker bridge); peer dependencies are eslint, eslint-config-prettier, and prettier, reflecting that the plugin does no bundling of its own and defers entirely to the host project’s installed versions. Devtooling is comprehensive: a recent major-version ESLint running in flat-config mode (dogfooding itself via plugin:prettier/recommended), Mocha for tests, Changesets for versioned releases, commitlint plus simple-git-hooks for commit discipline, and a pnpm workspace with a patched dependency supporting the remark-based docs lint pipeline.

Code Quality

Tests live under test/ as numbered .txt fixture files covering dozens of formatting scenarios plus named edge cases (Vue, GraphQL, MDX, JSON), driven through Mocha via test/prettier.mjs — a snapshot-style fixture approach well suited to a rule whose job is literally “does the diff match.” Error handling is explicit: both the rule and the worker special-case SyntaxError from Prettier and re-throw anything unexpected, and the rule strips Prettier’s redundant code-frame text from re-reported messages. Typing is done via JSDoc @ts-check annotations and @import typedefs rather than compiled TypeScript, checked by lint and format scripts that run in CI. Test fixture coverage across markdown/html/graphql/vue/svelte edge cases is notably thorough for a package this size.

API Design The plugin’s entire public surface is one rule name (prettier/prettier) plus two ready-made config exports, about as low-boilerplate as an ESLint integration gets — most consumers add a single extends entry or import the flat-config object and never touch the rule’s options directly. The rule’s own options mirror Prettier’s own API rather than inventing new configuration vocabulary, keeping the learning curve close to zero for anyone who already knows Prettier. The README documents edge cases thoroughly (Svelte support caveats, a documented arrow-body-style/prefer-arrow-callback interaction bug) rather than just happy-path usage. Running a formatter through a linter’s fixer mechanism is a well-established pattern predating this package, so it isn’t technically novel — but the developer experience is exemplary for its category.