Bun、フォーマッタ「bun fmt」をPrettier本体より最大286倍速く搭載

保存するたびに、あるいはコミット前のチェックで、Prettierの整形が終わるのを待っている。本サイトは10月、Bunが型チェッカーbun checkを組み込み、TypeScript公式より最大6.4倍速く動くと伝えた。型チェックの次に時間を取られるのは、コードの整形だ。2026年10月22日公開のBun v1.4.4は、ここにも手を入れた。コマンドはbun fmt。今使っているPrettierの設定ファイルはそのままに、整形だけを大きく速くできるという。

何が追加されたのか

bun fmtは、Bunのランタイムに直接組み込まれたコードフォーマッタだ。公式ドキュメントは「インストールするものも、設定するものも無い」と説明している。.prettierrcやprettier.config.*、package.json内の"prettier"フィールドをそのまま読み込み、.editorconfigの指定も反映する。

これまでPrettierを使っていたプロジェクトなら、package.jsonのformatスクリプトをbun fmtに書き換えるだけで移行できる。既存のformatスクリプトがあれば自動で検出して実行するため、呼び出し方を覚え直す必要もない。対応言語はJavaScript、TypeScript、CSS、HTML、Vue、Svelte、JSON、YAML、Markdownなど22種類に及ぶ。

設定を1行も書かなくても、printWidthやsemiなどの初期値はPrettierの既定値と揃えてある。さらに次の整形機能が組み込み済みで、bunfig.tomlの[fmt]セクションで有効にできる。

• import文の並べ替え(sortImports)
• Tailwindのクラス順の整列(sortTailwindcss。プロジェクトにtailwindcssがインストールされている場合のみ動く)
• package.jsonのキー整列(sortPackageJson)
• JSDocの整形(jsdoc)

これまでprettier-plugin-tailwindcssやprettier-plugin-packagejsonを個別にインストールしていた場合、その依存をbun fmt側の設定に置き換えられる。何ができるかは分かった。次に気になるのは、保存のたびに待っていた時間が実際どれだけ縮むかだ。

どれだけ速いのか

まず、実際のオープンソースプロジェクトで比べた数字から見てみる。公式ブログは、高速フォーマッタとして知られる「oxfmt」(Oxcチームが開発する、Biomeのフォーマッタを土台にしたツール)とbun fmtを比較している。viteのリポジトリ(JS/TSファイル2,537件)を、それぞれのプロジェクトの設定のまま整形した時間が次のグラフだ。

この計測は16コアのApple M4 Max(macOS 26.7)での平均値だ。他のプロジェクトでも同じ傾向か、公式ブログが載せている表の数字を並べてみる。

• RSSHub(7,121ファイル): oxfmt 298.5ms → bun fmt 97.3ms(3.0倍)
• redocly-cli(3,397ファイル): oxfmt 217.5ms → bun fmt 62.4ms(3.4倍)
• vite(2,537ファイル): oxfmt 406.7ms → bun fmt 65.2ms(6.2倍、上のグラフと同じ値)
• fumadocs(2,452ファイル): oxfmt 1,395ms → bun fmt 44.6ms(31倍)

公式ブログは本文で「oxfmt比で3倍から6倍」とまとめているが、fumadocsだけ表で31倍になっている。食い違いの理由は記事に説明がなく、自分も読みながら一度止まった。oxfmt自身がすでに「速いフォーマッタ」として知られているので、3〜6倍の範囲ならまだ驚くほどの数字ではないかもしれない。

比較対象をPrettier本体に変えると、桁が変わる。公式ブログは、Prettier自身のリポジトリ(2,616ファイル、同じ設定)を整形する時間も計測している。Prettier 3.9.10が17.1秒かかる処理を、bun fmtは59.7ミリ秒で終える。約286倍、ピークメモリも459MBから48MBへ約9.6分の1になる。自分が意外だったのは、この計測がほかでもないPrettier自身のソースコードを使っていたことだ。比較ツールが自分のコードを使って測っている素直さに、説得力を感じた。

vitestやdate-fns、monkeytype、h3といった他の実プロジェクトでも、Prettier比では234倍から425倍の差が報告されている。oxfmt比では数倍、Prettier自身の処理時間比ではさらに桁が上がる。この二段構えが、「bun fmtは何倍速いのか」という問いに単一の答えがない理由だ。

この速さは、複数コアを使っているからだと思うかもしれない。公式ブログは1コアだけに固定した計測も載せている。RSSHubで1.9倍、fumadocsで21倍と、8コア計測(3.0倍・31倍)より数値は下がるものの、oxfmtより速い傾向は1コアでも変わらない。並列化は差を広げる一因ではあっても、速さの土台ではないことになる。ここまでは速さの話だ。速くなった分、出力の中身まで変わっていないかが次に気になる。

出力の精度は保たれているか

速いだけなら、整形結果が変わってしまっても達成できる。bun fmtはPrettierを一から移植し直した別実装なので、出力が本当に揃っているかは検証するしかない。公式ブログが報告している一致率は次のとおりだ。

Prettier公式のテストでは、ほとんどの言語で一致率がほぼ100%に近い。YAMLだけ95.9%にとどまり、差分の大半はブロックスカラーの末尾空行の扱いを意図的に変えていることが理由だと記事にある。

実在するプロジェクトとの比較で、oxfmt比(94.6%)がPrettier比(77.0%)より高いのは理由が読み取れる。bun fmtのJS/TSプリンタ自体が、Oxcのoxc_formatter(Biomeのフォーマッタの移植)を土台にしているからだ。oxfmtも同じ系譜のツールなので、出発点が近い相手ほど一致しやすい。精度は十分でも、実際に乗り換えようとすると設定がそのまま通用しない場面も残っている。

乗り換えで気をつけること

公式ドキュメントには、読者の判断が変わる留保が3つ書かれている。

• Astroは組み込まれていない。Astro用プラグインが設定されたファイルは、インストール済みのPrettierにフォールバックして整形される
• 対応していないPrettierプラグインを使っている場合、そのファイルは整形されずスキップされ、終了コードが2になる。CIでこの終了コードを拾っていると、ビルドが止まる
• YAMLのブロックスカラー末尾の空行は、Prettierが削除するところをbun fmtは保持する。既存ファイルに差分が出ることがある

bun fmt --doctorを実行すると、設定の解釈結果と、削除できる不要なPrettierプラグインが表示される。乗り換え前に一度試しておく価値がある。

まとめ

Bun v1.4.4(2026-10-22)のbun fmtは、既存のPrettierやoxfmtの設定ファイルをそのまま読み込む。package.jsonのformatスクリプトを書き換えるだけで試せるフォーマッタだ。速さは比較対象によって桁が変わり、oxfmt比で数倍、Prettier自身のリポジトリ整形では約286倍になる。それでいてPrettier公式テストでは99.1%が完全一致しており、出力が大きく変わる心配は小さい。Astro非対応、未対応プラグインのスキップ、YAML末尾空行の3点だけ確認してから、保存のたびに待っていた時間を試してみるとよい。