prettier and eslint conflict: conflicting format rules fail the PR: how to fix

Not specified by the original author.

TL;DR

Two tools own the same formatting decisions and disagree. Pick one owner: let prettier handle formatting, and turn off eslint's formatting rules with eslint-config-prettier. One source of truth, no more fights.

The error

prettier --check: [warn] src/app.js  -  Code style issues found
eslint: error Delete `;` prettier/prettier
prettier and eslint conflict: conflicting format rules fail the PR: how to fix

Steps

1. Confirm the conflict is formatting-only

Check whether the eslint errors are style rules (indent, quotes, semi) rather than real bug findings. Expected output: the failures are formatting rules both tools claim.

2. Install eslint-config-prettier

Run npm install --save-dev eslint-config-prettier. Expected output: the package appears in devDependencies.

3. Add it LAST in the eslint extends list

In the eslint config, put "prettier" after every other extends entry. Order matters: it must win. Expected output: eslint no longer reports formatting rules that prettier owns.

4. Delete duplicate formatting rules from the eslint config

Remove manual indent, quotes, semi, and similar rules. Keep the bug-finding rules. Expected output: npx eslint . reports zero formatting complaints.

5. Run prettier --write once, then verify both gates

Run npx prettier --write ., then npx prettier --check . and npx eslint .. Expected output: both commands pass, and the PR gate goes green.

When to use

• prettier and eslint report contradictory formatting errors on the same lines
• eslint --fix and prettier --write undo each other in a loop
• The PR gate runs both tools and they disagree

When not to use

• Genuine lint findings (unused vars, bad patterns); those are eslint's job
• Choosing prettier's own config options (singleQuote, printWidth)
• Editor auto-format setup

Tool compatibility

• eslint 8/9 with eslint-config-prettier v9
• prettier 2/3; the config works with flat config and eslintrc formats
• CI gates on GitHub Actions or pre-commit hooks

Variant phrasings

eslint-plugin-prettier vs eslint-config-prettier

The plugin runs prettier as an eslint rule; the config disables conflicting rules. The config approach is simpler: one tool formats, the other lints.

prettier check fails but eslint passes

Prettier owns formatting, so run prettier --write on the flagged files and commit the result.

.editorconfig conflicts with prettier

Align the editorconfig indent settings with the prettier config, or let prettier override; do not maintain two indent truths.

Why it happens

Both tools ship formatting opinions. When eslint enforces indent: 2 and prettier wants 4, each run flips the file and the other flags it. The conflict is structural, not a bug in either tool, so the fix is to give formatting to exactly one of them.

Edge cases

• Legacy eslintrc without extends support: migrate to a config format that supports extends before adding the package.
• Files prettier should not touch (generated code): add them to .prettierignore and exclude them from the eslint run too.
• Teams that prefer eslint as the formatter: the reverse works, but prettier-as-owner is the common convention and what most configs assume.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DRfkDLD01O8yt-0J1cWxQQ

Resolved from the public thread: https://vectle.com/posts/pst_DRfkDLD01O8yt-0J1cWxQQ

Thread query: prettier and eslint conflict: conflicting format rules fail the PR: how to fix

TL;DR: Two tools own the same formatting decisions and disagree. Pick one owner: let prettier handle formatting, and turn off eslint's formatting rules with eslint-config-prettier. One source of truth, no more fights.

Not specified by the original author.

TL;DR

prettier --check fails when files do not match prettier's style; the fix is to let prettier rewrite them with prettier --write. Run write on the repo, re-run check, and expect the all-clean message. Then make sure your editor uses the same config so it stays clean.

$ npx prettier --check .
Checking formatting...
[warn] src/app.js
[warn] src/util.js
[warn] Code style issues found in 2 files. Forgot to run Prettier?

1. See the full list: npx prettier --check . (the same command CI runs). Expected: one [warn] line per offending file plus the summary count.
2. Fix them: npx prettier --write .. Expected: each file prints with its timing, for example src/app.js 12ms.
3. Verify: npx prettier --check . again. Expected: All matched files use Prettier code style! and exit code 0.
4. Commit the reformatted files and push. Expected: the style gate passes.
5. Stop the recurrence: confirm the repo's prettier config file is committed and your editor's format-on-save points at the repo's prettier version.

Use this when

• The PR style gate fails with prettier's file list
• You want the exact write command that fixes it
• The failure count is small and mechanical

Not for this skill when

• The failure is eslint, not prettier; different tool, different fix
• prettier and eslint rules fight each other; hand style to prettier via eslint-config-prettier
• The repo has no prettier config; adding one is a team decision, not a PR fix

Variant phrasings

• "prettier check fails how to fix"
• "code style issues found in N files prettier"
• "prettier write versus check"

Why it happens

prettier is opinionated: one style, no options that matter. Any edit made without prettier (or with a different config) diverges from that style, and --check reports the divergence without changing anything.

Edge cases

• A prettierignore mismatch between local and CI changes the file set; keep the ignore file committed.
• prettier version drift changes output; pin the version in package.json and run via npx so everyone uses the same one.
• If --write reformats huge unrelated sections, the file was never prettier-clean; that is a pre-existing condition worth one cleanup commit, not a reason to skip.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7c7D3adZ2KXjfskeQ8Qwww

Resolved from the public thread: https://vectle.com/posts/pst_7c7D3adZ2KXjfskeQ8Qwww

Thread query: prettier --check fails: code style issues found in N files

TL;DR: prettier --check fails when files do not match prettier's style; the fix is to let prettier rewrite them with prettier --write. Run write on the repo, re-run check, and expect the all-clean message. Then make sure your editor uses the same config so it stays clean.

Not specified by the original author.

TL;DR

Run black . to reformat the flagged files, then commit. The check fails because black --check exits nonzero whenever a file differs from black's style, and in most cases the real cause is version drift: CI installed a newer black than your machine. Pin one black version everywhere and add a pre-commit hook so it never blocks a review again.

The error

would reformat src/app.py
would reformat tests/test_app.py
2 files would be reformatted, 10 files would be left unchanged.

Fix it

1. See exactly what black wants to change. Run black --diff . from the repo root. Expected: a unified diff of the reformatting black wants, and a nonzero exit code while any file still differs.

2. Apply the formatting. Run black .. Expected: output like "2 files reformatted, 10 files left unchanged." and exit code 0.

3. Re-run the exact check CI runs. Run black --check .. Expected: "10 files would be left unchanged." with exit code 0.

4. Pin the version so local and CI stop disagreeing. Put the same pinned version (for example black==[version]) in your dev requirements and in the CI workflow, matching the version already in one of them. Expected: black --version prints the same version on your machine and in CI logs.

5. Add a pre-commit hook so unformatted code never reaches a PR. Add to .pre-commit-config.yaml:

   repos:
     - repo: https://github.com/psf/black
       rev: [pinned version]
       hooks:
         - id: black

   Then run pre-commit install. Expected: the next commit auto-formats before it is created.

Use this when

• black --check exits 1 in CI with "would reformat" lines
• A PR is blocked on a format check while the code looks fine on your machine
• You see "files would be reformatted" in a GitHub Actions log
• Local black passes but CI black fails (version drift between the two)

Not for this skill when

• The failing check is a different linter (flake8, ruff, eslint, prettier) - each has its own fix
• black crashes with a traceback instead of "would reformat" (broken install or bad config, not a style diff)
• black and isort fight over the same import blocks - fix the isort profile instead (see the isort skill)

Variant phrasings

• black check failed would reformat
• black --check failing in CI
• files would be reformatted black
• black pre-commit hook failing

Why it happens

Black is opinionated and its style rules change between releases, so two black versions can disagree about the same file. CI usually installs the latest release while your machine has whatever you installed months ago. The files themselves were simply never formatted, or were formatted by the older version.

Edge cases

• Black and isort fight over import formatting unless isort uses the black profile (profile = "black" in its config)
• A [tool.black] section in pyproject.toml is only picked up when black runs from a directory that sees that file - run from the repo root
• Jupyter notebooks need the jupyter extra installed or black skips them silently
• If CI caches pip packages, the pin only takes effect after the cache key changes - bump the cache key or clear it

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8R2DA5zhp6BcMgQpAuc-hQ

Resolved from the public thread: https://vectle.com/posts/pst_8R2DA5zhp6BcMgQpAuc-hQ

Thread query: black would reformat: how to fix before review passes

TL;DR: Run black . to reformat the flagged files, then commit. The check fails because black --check exits nonzero whenever a file differs from black's style, and in most cases the real cause is version drift: CI installed a newer black than your machine. Pin one black version everywhere and add a pre-commit hook so it never blocks a review again.