How to check prettier formatting

Run npx prettier --check . in the project root. It prints one [warn] line per file whose formatting differs from what Prettier would write, then a count, and exits 1. A tree that already matches prints All matched files use Prettier code style! and exits 0. Nothing on disk changes.

Why check this

Formatting is a gate in the pull request job, next to the lint and type checks. Its value is not tidiness, it is diff size: one reformatted file turns a three-line change into a three-hundred-line review, and the real edit hides inside it.

The failure this catches on Windows is different, and it is the one that wastes an afternoon. A check fails on a file nobody in the team has opened, because the working copy has CRLF line endings and Prettier writes LF. The tool reports a formatting problem, the developer opens the file, and the two versions look identical on screen.

Prerequisites

• Node 18 or later. This page used Node 22.23.2.
• Prettier as a dev dependency, so CI and every laptop check against one version. The options reference documents each flag below.
• No configuration file, so Prettier 3 defaults apply: printWidth 80, double quotes, semicolons, and endOfLine set to lf.
• The project below, which produced every block on this page. src/price.js is already formatted. src/tag.js is not. src/legacy.js holds the same characters as src/price.js with CRLF endings.

// src/price.js, formatted by Prettier, LF endings
export function price(cents, currency) {
  return new Intl.NumberFormat("en-US", { style: "currency", currency }).format(
    cents / 100,
  );
}

// src/tag.js, spacing and quotes that Prettier disagrees with
export function tag( name ,value ){
    return name+':'+value
}

node -e "const fs=require('fs');fs.writeFileSync('src/legacy.js',fs.readFileSync('src/price.js','utf8').replace(/\n/g,'\r\n'))"

Steps

1. 1

   Step 1.

   Read the Prettier version the project resolves to. Output rules change between major versions, so a result without a version is not comparable.

   npx prettier --version
   

   3.9.6

2. 2

   Step 2.

   Check the tree and read the exit code.

   npx prettier --check . --no-color; echo "exit=$?"
   

   Checking formatting...
   [warn] src/legacy.js
   [warn] src/tag.js
   [warn] Code style issues found in 2 files. Run Prettier with --write to fix.
   exit=1

   Two files, one count line, exit 1. --no-color drops the escape sequences, which keeps a CI log readable.

3. 3

   Step 3.

   Ask what Prettier would write for one of them. --check names files and never shows the difference.

   npx prettier src/tag.js --no-color
   

   export function tag(name, value) {
   return name + ":" + value;
   }

   With no --write and no --check, the formatted result goes to stdout and the file is untouched. Compare it with the original by eye, or pipe it into diff.

4. 4

   Step 4.

   Compare the other flagged file with the one that passed.

   node -e "const fs=require('fs');const a=fs.readFileSync('src/legacy.js','utf8'),b=fs.readFileSync('src/price.js','utf8');console.log('same text:',a.replace(/\r/g,'')===b,'| CR bytes:',(a.match(/\r/g)||[]).length)"
   

   same text: true | CR bytes: 5

   Remove the carriage returns and the two files are the same string. The only difference Prettier found is five bytes no editor displays.

5. 5

   Step 5.

   Prove it by running the same check with CRLF accepted.

   npx prettier --check src/legacy.js --no-color --end-of-line crlf; echo "exit=$?"
   

   Checking formatting...
   All matched files use Prettier code style!
   exit=0

   Same file, same content, opposite verdict. The failure in step 2 was the endOfLine default, not the code.

6. 6

   Step 6.

   Read the Git setting that produces those endings on Windows.

   git config --get core.autocrlf
   

   true

   true means Git converts LF to CRLF on checkout. Every file in the working copy then disagrees with the Prettier default, whether or not anyone edited it.

How to read the result

| What you see | What it means | What to do | | --- | --- | --- | | All matched files use Prettier code style!, exit 0 | Every file Prettier matched is formatted | Nothing. Record the version from step 1. | | [warn] lines and exit 1 | Those files differ from Prettier output | Run npx prettier --write on them and review the diff before committing. | | A file you never touched is flagged | Line endings, encoding or a version bump | Run step 4 on it. If the text matches after removing \r, the cause is CRLF. | | Every file is flagged after an upgrade | A default changed in a Prettier major | Reformat the tree in one commit of its own, so the next review has a clean diff. | | [error] No files matching the pattern were found and exit 2 | The path argument matched nothing | Check the working directory. Exit 2 is a usage failure, not a formatting result. |

Common mistakes

What to check next

• How to check eslint errors: the rule check that runs beside this one, and what its exit code means.
• How to check typescript errors: the third command in the same gate, with an exit code of 2.
• How to check if a build is reproducible: line endings change file bytes, which is the same thing that moves a build hash.
• How to check installed npm package version: confirms the Prettier version when two machines disagree about the same file.
• Pull request checklist: where the formatting gate sits among the rest.

FAQ

How do I check formatting without changing files?

npx prettier --check . reads and reports. It writes nothing. --write is the flag that edits, and --list-different prints the same file list as --check with no summary line.

Why is a file flagged when the code looks identical?

Its line endings differ. Step 4 removes the carriage returns and the two files match. Prettier defaults endOfLine to lf, so a CRLF working copy fails on every file it contains.

Should I set endOfLine to auto?

It hides the problem rather than fixing it. --end-of-line auto on src/legacy.js exits 0, and so does the CRLF file that Git will commit next. Fix the checkout with .gitattributes and keep the default.

What exit code does prettier return?

0 when every matched file is formatted, 1 when at least one is not, and 2 when the invocation itself failed, such as a path that matches no file. Treat 2 as a broken command rather than a formatting result.

Which files does the check cover?

Every file under the path whose extension Prettier has a parser for, minus node_modules and anything in .prettierignore. That includes JSON, Markdown and CSS, so a formatting job touches more than the source tree.

Verified