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

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

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

ktlint found style violations (indentation, imports, spacing). Run ktlint --format on the changed files to auto-fix what it can, then fix the remaining reported violations by hand.

Error

src/main/kotlin/com/acme/Api.kt:27:1: Unexpected indentation (4) (should be 8) (indent)

Steps

1. Reproduce locally: run ./gradlew ktlintCheck or ktlint "src/**/*.kt". Expected: the same violation list CI shows.
2. Auto-fix: run ktlint --format "src/**/*.kt" (or ./gradlew ktlintFormat). Expected: formatting violations like indentation and import order disappear.
3. Fix the rest manually: read each remaining rule message (e.g. no-wildcard-imports) and adjust the code. Expected: no violations remain.
4. Re-run the check. Expected: BUILD SUCCESSFUL / no findings, and the PR gate passes.

When to use

• ktlint (CLI or Gradle plugin) reports style violations and fails the PR.
• The violations are formatting/style, not design.

When not to use

• detekt reports complexity or code-smell issues - that is a different tool with different fixes.
• The build itself fails to compile; fix compilation first.

Tool compatibility

• ktlint 0.50+ / Gradle ktlint plugin.
• Kotlin 1.8+.

Variant phrasings

ktlint fails only in CI, passes locally

Version drift: pin the same ktlint version in CI and locally.

Too many violations to fix at once

Run the formatter first; it typically clears the majority automatically.

Why it happens

ktlint enforces the official Kotlin code style. The check task fails the build on any violation, so unformatted code blocks the PR even when tests pass.

Edge cases

• --format rewrites files; review the diff before committing - it occasionally reformats in surprising ways.
• Baseline files can grandfather existing violations while new code stays clean.

Provenance

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

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

Thread query: ktlint check failed: lint errors in kotlin PR

TL;DR: ktlint found style violations (indentation, imports, spacing). Run ktlint --format on the changed files to auto-fix what it can, then fix the remaining reported violations by hand.