Bun fmt vs Prettier: Migration Without Formatting Surprises

Before we dive in, why not take a quick peek at my portfolio: https://priyalraj.com

📋 TL;DR: What You’ll Learn Here

• Bun 1.4.4 adds bun fmt, with support for existing Prettier configs.

• Check before writing: inspect compatibility, compare output, then change scripts.

• Plugins decide migration scope. Astro projects still need their Prettier fallback.

• Editor, hooks & CI need agreement. Faster CLI alone doesn’t finish migration.

🥟 What Changed in Bun 1.4.4?

Bun 1.4.4 shipped October 22, 2026, adding bun fmt. Formatting now comes inside Bun, alongside its other tooling. Existing Prettier or oxfmt config can carry across.

For my projects, appeal starts with fewer moving parts. One less command installed separately sounds useful. But client repos carry years of formatting decisions: ignored generated files, plugin options, editor settings & CI assumptions. Those decisions matter more than swapping executable names.

Think of formatter migration like changing printers in an office. Both print documents. Still need margins, paper sizes & special forms checked before sending every invoice through replacement.

Bun publishes performance measurements in its release notes. Treat those as Bun’s benchmarks, measured against particular repos & versions. No promised speedup here: measure your files, on your machine, with your actual config.

My tip: First goal: predictable output. Timing comes after compatibility. Saving seconds won’t help if every developer’s editor rewrites yesterday’s commit. 😅

🔎 Start With Config, Not Package Removal

Keep existing formatter installed during evaluation. Prettier recommends an exact local version, because formatting output can change across releases. That gives comparison work a stable baseline.

Run existing format check first. If baseline already fails, record why before adding another formatter. Otherwise old formatting debt gets blamed on new tooling.

Then inspect Bun’s interpretation:

# terminal, with Bun 1.4.4 installed
bun --version
bun fmt --no-script --doctor
bun fmt --no-script --check

Bun’s migration guide documents --doctor as inspection without formatting. Read its plugin report carefully. It also warns that CI files, hooks & other tools’ configs aren’t checked automatically.

That last point deserves manual work. Search repo scripts, editor settings & workflow files for formatter commands. Include nested packages. Root script can look correct while one workspace still calls old command directly.

Build short inventory: supported file types, config location, excluded dirs, plugin names, editor formatter & CI entry point. Keep it beside migration PR. Reviewer should understand exactly which formatting behavior owns each file.

🧪 Compare Same Files From Same Baseline

Don’t start with whole-repo write while feature changes sit unstaged. Use clean branch or disposable worktree. Keep comparison outside active feature work, then inspect resulting diff normally.

Prettier’s CLI docs distinguish checking from writing: --check reports style problems, while --write updates files. bun fmt writes by default. Command resemblance can hide different behavior.

Use bunx prettier here only with Prettier already installed locally. Avoid accidentally downloading another version for your comparison.

For pilot, choose representative files: TSX component, TypeScript module, stylesheet, Markdown page & config. Include file using each plugin. Include awkward files, too: long expressions, embedded snippets, intentional ignore comments & nested overrides.

Run each formatter against identical starting content. Compare full output, including file coverage. A formatter that skips special files can appear faster while doing less work.

My tip: Review filename list before reviewing whitespace. Unexpected generated file or missing framework component often reveals bigger issue than quote changes.

🧩 Plugin Support Determines What Can Go

Prettier plugins can supply languages or formatting behavior outside core package. Removing plugin deps without understanding their role risks leaving files unformatted.

Bun’s release notes cover built-in plugin equivalents, including Tailwind class sorting & import sorting. But Astro isn’t built in: configured Astro files go to installed Prettier. Keep prettier & prettier-plugin-astro when that fallback applies. Bun’s doctor report identifies those files.

For unsupported plugins, migration guide describes skipped files & exit code 2. Don’t treat skipped coverage as successful migration. Investigate unsupported behavior before enabling any bypass.

My decision rule: migrate only file coverage verified. If repo needs plugin fallback, accept that hybrid setup while evaluating it. Deleting deps isn’t prize. Consistent formatting across every maintained file is prize.

✅ Keep framework plugin deps until fallback verified.

✅ Test plugin-heavy files separately from plain JavaScript.

❌ Remove every package named prettier because basic .ts check passed.

❌ Treat unsupported-plugin failure as permission to discard team formatting rules.

📁 Keep Config & Ignore Rules Familiar

Leave .prettierrc in place for first migration. Changing formatter, config format & style policy together creates unnecessary variables. Prettier resolves config relative to file being formatted, so nested packages deserve explicit checks.

Example shared config:

// prettier.config.mjs
export default {
  semi: true,
  singleQuote: true,
  printWidth: 100,
};

Use your existing values, not mine. Migration shouldn’t become surprise style vote.

Prettier’s ignore docs describe .prettierignore for excluding files & inline comments for preserving specific code. Keep those exceptions visible. Generated files, vendor code & copied fixtures often need intentional treatment.

During review, ask why each exclusion exists. Some protect generated output; others preserve externally maintained files. Deleting exclusion can create hundreds of lines unrelated to application behavior.

Also test commands from real working dirs. Root-only success doesn’t prove workspace script behaves identically. Write down where CI runs, where developers run hooks & whether editor opens repo root or individual package.

🛠️ Switch Scripts After Pilot Passes

Once output & coverage meet expectations, update existing scripts. JSON block below is fragment for existing scripts object, not replacement for whole manifest:

// package.json, merge into existing scripts
{
  "scripts": {
    "format": "bun fmt --no-script",
    "format:check": "bun fmt --no-script --check"
  }
}

Watch command-name collision: project fmt script takes precedence when invoking bun fmt. --no-script explicitly selects formatter. Audit existing fmt script before deciding whether to rename it or preserve wrapper behavior.

Don’t use broad search-and-replace across shell commands. Some scripts expect formatted text on stdout, others expect in-place writes. Bun’s guide calls out this distinction; review intent of each invocation.

Keep formatting-only changes separate from script/config changes where practical. Reviewers can assess tool wiring independently, then inspect mechanical diff without hunting application edits through changed indentation.

🚦 Align CI, Hooks & Editor

Bun formatter docs specify check exits: 0 for clean files, 1 when formatting needed, 2 for errors. CI should fail on either nonzero result, while logs preserve distinction.

Minimal job steps, appended to your existing workflow:

# .github/workflows/ci.yml, excerpt
steps:
  - uses: actions/checkout@v4
  - uses: oven-sh/setup-bun@v2
    with:
      bun-version: "1.4.4"
  - run: bun install --frozen-lockfile
  - run: bun run format:check

Pin same Bun version during rollout. Update deliberately later, with another output check. A dev machine & CI should agree before branch protection starts enforcing new command.

Try formatting from editor, then run CI check locally. If file alternates between two outputs every save, stop rollout & inspect editor formatter selection. Keep local Prettier if editor still depends on it.

Hooks need testing with real staging habits. Bun’s --staged mode formats staged files & stages results, with special handling for partially staged files. Test that behavior in disposable branch before replacing existing hook.

📏 Measure Useful Speed, Keep Bug Checks

My benchmark plan: compare normal developer task, not cherry-picked snippet. Record installed versions, file set, machine & repeated run times. Separate cold startup from warm runs. Keep plugin fallback work included.

If main frustration is slow pre-commit checks, measure hook. If CI is problem, measure complete job. Install time, cache restore & runner startup can dominate short formatter command.

Finally, keep lint, type checks & tests. Prettier explains formatting versus code-quality rules: consistent layout doesn’t replace checks for bugs. Changing formatter gives no reason to remove unused-variable checks or skip application tests.

Acceptance checklist: expected file coverage, reviewed diff, matching editor output, passing CI & reversible script change. Stop once those hold. New formatter doesn’t require rewriting rest of toolchain.

Final Thoughts

For my repos, bun fmt earns trial through existing config support & practical migration path. Adoption still needs evidence from repo itself.

Start read-only, test difficult files, preserve plugin fallback & make editor agree with CI. Keep comparison branch easy to discard. Once output behaves predictably, speed becomes useful bonus instead of reason to rush. 🙂

If you enjoyed this article, please make sure to follow me on Twitter.