Bunを読む：ランタイム、パッケージ管理、バンドルを一つの実行ファイルに

bun実行ファイルに集約された役割

BunのREADMEは、BunをJavaScriptとTypeScriptアプリのためのall-in-one toolkitと説明し、bunという単一実行ファイルを配布しています。中核のBun runtimeはRustで書かれ、内部ではJavaScriptCoreを使う高速なランタイムで、Node.jsのdrop-in replacementを目指すとされています。CLIにはランタイム以外にテストランナー、スクリプトランナー、Node.js互換のパッケージマネージャーも含まれます。役割が一つにまとまることと、既存プロジェクトの互換性が保証されることは別に評価します。

TypeScriptとJSXを直接実行する入口

READMEにはbun run index.tsxの例があり、TypeScriptとJSXを追加の設定なしで扱えると説明しています。bun testはテスト、bun run startはpackage.jsonのstartスクリプト、bun install <pkg>はパッケージ導入、bunx cowsay 'Hello, world!'はパッケージ実行の例です。これは最初の操作を理解するための短い例で、既存のビルド、テスト、ライフサイクルスクリプトがそのまま同じ結果になる証明ではありません。移行前に依存の解決、モック、ネイティブ拡張を確認してください。

OSとCPU要件を先に固定する

Bunはx64とarm64のLinux、x64とApple SiliconのmacOS、x64とarm64のWindowsを対象にしています。Linuxではカーネル5.6以上を強く推奨し、最低5.1とREADMEに記載されています。x64でillegal instructionのようなエラーが出た場合はCPU要件を確認するよう案内されています。開発者の端末だけで確認せず、CI、コンテナ、配布先のCPUとカーネルを同じ表に記録してください。アーキテクチャが違えば、速度だけでなく実行可否も変わります。

導入経路とcanary更新を分ける

READMEはUnix系のインストールスクリプト、WindowsのPowerShell、npmのグローバル導入、Homebrew、Dockerイメージを示しています。通常版の更新はbun upgrade、mainへの各コミットで作られるcanaryはbun upgrade --canaryです。便利な更新コマンドほど、CIや本番で無意識に実行されない制御が必要です。インストール経路、取得した版、ロックファイル、イメージのdigestを保存し、canaryを使う環境と固定版を使う環境を明確に分けてください。

組み込みライブラリとライセンスの読み分け

READMEのライセンス節はBun自体をMITとしながら、JavaScriptCoreとWebKitを静的リンクし、LGPL 2の条件が関係すると説明しています。静的リンク時には、利用者がライブラリを変更して再リンクできるよう、アプリケーションをオブジェクト形式で提供する要件が示されています。boringssl、brotli、libarchive、mimalloc、zstdなどの静的リンク物とポリフィルも列挙されています。配布物を作る場合はBunのLICENSE.mdだけで終わらせず、同梱コンポーネントと再リンク条件を確認してください。

採用判断は互換表ではなく自分の依存で行う

素材取得時のメタデータでは、BunはRust、リポジトリは非アーカイブで、約9万5773スター、5018フォーク、8593件のオープンissueが記録されています。READMEの説明にはMITとLGPLの条件、公式ドキュメント、issue、roadmapへのリンクがありますが、サービス保証や自分のアプリの成功率は書かれていません。Node.jsから置き換えるなら、HTTP、ファイル、暗号、子プロセス、テスト、依存解決を実際のワークロードで比較し、失敗時に戻せる切り替え手順を用意してください。評価環境では通常版とcanaryを混ぜず、bunの版、OS、CPU、カーネル、インストール経路、lockfileを保存します。既存のpackage.jsonを使い、スクリプトの終了コード、標準出力、環境変数、パス解決、Node.js用パッケージの読み込み結果を比較します。バンドルを使う場合は出力物の形式とsource map、テストを使う場合はモックとスナップショット、パッケージ管理を使う場合は依存解決と監査結果を別々に確認します。Dockerではイメージのタグだけでなくdigestと実行ユーザーを記録してください。高速さを一つの数値で決めず、実際の開発と配布に必要な挙動を確認し、問題が出た機能だけNode.jsの既存経路へ戻せる段階導入にします。bun build、ローダー、workspaces、ライフサイクルスクリプトを使う場合は、npmの既存結果と成果物の差分を確認します。パッケージ監査やpublishを使う場合は、レジストリ、認証情報、公開範囲を別の手順に分けます。Bun本体と静的リンクされるLGPL系ライブラリの条件を配布物へ反映できるかも確認し、性能の数値を環境外へ一般化しないでください。さらに、bun installで作成されるlockfileをCIのレビュー対象にし、依存更新前後の解決結果を比較します。Node.js互換の説明は機能ごとに検証し、ネイティブ拡張や子プロセスで差が出た場合はその範囲だけ切り離します。

Node.jsから移す機能を一つずつ決める

Bunを導入する場合は、まず既存package.jsonのscriptsをbun runで実行し、次にbun test、bun install、bunx、Bun.buildを別々の段階で評価します。HTTP、ファイル、暗号、子プロセス、環境変数、モジュール解決、ネイティブ拡張の結果をNode.jsと比較し、終了コード、標準出力、lockfile、postinstall、監査結果を保存します。TypeScriptとJSXを直接実行できる説明は、既存の設定や依存が不要になる保証ではありません。LinuxのカーネルとCPU命令、macOSのIntelとApple Silicon、Windowsのx64とarm64を分けて確認します。canaryは固定版と別に扱い、Dockerのタグ、digest、ユーザー、マウント先を記録します。MITのBun本体、JavaScriptCoreやWebKitのLGPL条件、他の静的リンク物を分けて確認し、問題が出た機能はNode.jsへ戻せる手順を残します。

実行環境と依存解決を同じ表で比べる

Bunの置き換え評価では、Node.jsで動いている同じpackage.jsonを使い、bun run、bun test、bun install、bunx、Bun.buildの結果を分けて保存します。終了コード、標準出力、環境変数、パス、依存解決、postinstall、ネイティブ拡張を比較し、機能単位で採用可否を決めます。LinuxのカーネルとCPU、macOSのIntelとApple Silicon、Windowsのx64とarm64は別条件です。固定版とcanary、ローカルとDockerを混同せず、タグ、digest、実行ユーザー、マウント、lockfileを記録します。BunのMIT条件と静的リンクライブラリのLGPL条件を分け、失敗時にNode.jsへ戻る手順を残します。

編集部の結論

Bunは、JavaScriptやTypeScriptの実行、依存の導入、スクリプト、テスト、バンドルを一つのCLIで扱いたいチームが試せる選択肢です。READMEはNode.jsのdrop-in replacementを掲げますが、互換性はプロジェクトと依存物の組み合わせで変わります。Linuxカーネル、CPU命令、OS、ネイティブ依存、ライセンス、更新経路を固定した検証を行い、Node.jsからの置き換え範囲を段階的に決めてください。BunはRustとJavaScriptCoreを使う単一実行ファイルで、bun run、bun test、bun install、bunxを提供します。READMEにはTypeScriptとJSXの実行、Node.js互換パッケージ管理、既存Node.jsプロジェクトで変更を抑えて使えるという説明がありますが、全依存物の互換性を保証するものではありません。Linuxはx64とarm64、macOSはx64とApple Silicon、Windowsはx64とarm64が対象で、Linuxカーネル5.6以上を強く推奨し最低5.1という注記があります。導入経路はスクリプト、PowerShell、npm、Homebrew、Dockerです。現行一覧のbun-v1.4.0とcanaryを分け、lockfile、CI、成果物、テスト、監査、ライセンス文書を固定してから判断してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes