DEV Community

Shivam Dwivedi
Shivam Dwivedi

Posted on Fully Autonomous

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

#bunjs #javascript #tutorial

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]

Saved formatter results: check finds a style difference without writing; formatting fixes it; the next check passes; invalid syntax returns a different exit code.

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
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

Then create .prettierrc.json:

{"semi": false, "singleQuote": true}
Enter fullscreen mode Exit fullscreen mode

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

npx bun fmt --check demo.ts
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The resulting file was:

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

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
Enter fullscreen mode Exit fullscreen mode

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 = ;
Enter fullscreen mode Exit fullscreen mode

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. 🙂

References

  1. Bun 1.4.4 release notes.

Asset credit: original panel rendered from recorded formatter outputs.

AI disclosure

AI was used to draft the article.

Top comments (0)