Bun has a formatter now. Start with the command that writes nothing.

The first useful result from my Bun formatter test was an exit code of 1. The file stayed exactly as I wrote it. ✅

That is a good first encounter with a formatter: find out what it wants to change before letting it rewrite a repository.

Bun 1.4.4, released on October 22, adds bun fmt. I tried its configuration and failure paths on a small TypeScript fixture. This is a working first-check guide, not a speed comparison. [1]

Original output panel rendered from the saved commands. The exit codes came from the actual Bun 1.4.4 run.

Give it one deliberately untidy file

In a disposable directory with npm available, install the pinned version:

npm install --save-dev bun@1.4.4
npx bun --version

The version should be 1.4.4. Keeping it local avoids replacing a runtime another project depends on. My verification used that package's executable directly.

Create demo.ts:

const message={text:"hello",count:2};
console.log(message);

Then create .prettierrc.json:

{"semi": false, "singleQuote": true}

This makes the expected changes visible: spacing, single quotes and no semicolons. Run the check first:

npx bun fmt --check demo.ts

My run returned 1 and identified the file as needing formatting. I compared the file bytes before and afterward: unchanged. The command failed its style check; it did exactly what I asked. 💡

Now allow the edit

npx bun fmt demo.ts
npx bun fmt --check demo.ts

The resulting file was:

const message = { text: 'hello', count: 2 }
console.log(message)

Both commands returned 0. The existing Prettier configuration controlled the result. I formatted it again and compared the bytes again: no further change. That is idempotence, meaning another pass leaves the result alone.

I also ran:

npx bun fmt --debug-check demo.ts

That returned 0. The release describes this as reparsing after formatting to check that the meaning has not changed. It is a useful extra check, rather than a substitute for the application's tests. [1] 🧪

A red check can mean different things

I replaced the input with deliberately invalid syntax:

const broken = ;

bun fmt --check bad.ts returned 2 with an expression-expected diagnostic. That differs from the style-only result of 1 on the valid file.

⚠️ If a CI log says the formatter failed, read the diagnostic before treating every failure as “run the fixer.” A parser cannot repair an arbitrary broken program by moving its spaces around.

The release also documents --staged, which formats staged files and stages the edits again. That is a different workflow from the read-only check above. Inspect the staged diff before adopting that hook. [1]

Where I would stop this first trial

This fixture checked configuration loading, unchanged check-mode bytes, formatting, a repeated pass, a parse-preservation check and syntax rejection. It did not establish compatibility with every plugin or prove the release's performance claims.

For an existing project, try its real files on a reversible branch, inspect the diff, and run its tests. A formatter being built into the runtime makes it convenient; your repository still gets a vote. 🙂