Bun v1.1徹底解説：新機能とNode.jsからの移行戦略

はじめに

Bunは、JavaScript/TypeScriptの実行、バンドル、テスト、パッケージ管理を一つに統合した、パフォーマンスを最優先に設計された「オールインワンJavaScriptランタイム」です。その圧倒的な速さから登場以来注目を集めてきましたが、これまではmacOSとLinuxが主なターゲットでした。

しかし、Bun v1.1のリリースにより、その状況は一変しました。このバージョン最大の目玉は、なんといってもWindowsへのネイティブサポートです。これにより、Bunは単なる「速いツール」から、あらゆる環境で利用できる「本格的なプロダクション利用の選択肢」へと大きく進化しました。

この記事では、Bun v1.1で追加された画期的な新機能、特に「Windowsサポート」と「bun shell」に焦点を当て、既存のNode.jsプロジェクトからの具体的な移行戦略と簡単なベンチマーク比較までを徹底解説します。

Bun v1.1の三大新機能

Bun v1.1は多くの改善を含んでいますが、特に重要な3つの新機能を紹介します。

1. 待望のWindowsネイティブサポート

これまでWindowsユーザーがBunを利用するには、WSL (Windows Subsystem for Linux) を経由する必要があり、一手間かかる状況でした。Bun v1.1では、この制約が完全になくなり、Windows 10以降（x64）にネイティブでインストールして実行できるようになりました。

インストール方法 (Windows): PowerShellを開き、以下のコマンドを実行するだけです。

irm bun.sh/install.ps1 | iex

これにより、開発体験が大幅に向上し、Windows環境でもBunの持つポテンシャルを最大限に引き出すことが可能になります。

2. クロスプラットフォームシェル bun shell

package.jsonのscriptsセクションにシェルコマンドを書く際、OS間の互換性に悩まされた経験は誰にでもあるでしょう（例: rm -rfはWindowsでは動かない）。bun shellは、この問題を解決する新しいクロスプラットフォームシェルです。

bun shellは、rm, cp, mv, echo, catといった基本的なシェルコマンドをBun自身に組み込んでおり、OSの違いを吸収してくれます。これにより、cross-envやrimrafといった補助的なnpmパッケージへの依存をなくし、package.jsonのスクリプトをシンプルに保つことができます。

使用例 (package.json):

{
  "scripts": {
    "clean": "bun shell rm -rf dist",
    "build": "bun run clean && tsc"
  }
}

このcleanスクリプトは、Windows、macOS、Linuxのいずれの環境でも、追加の依存関係なしにdistディレクトリを削除します。

3. さらなるパフォーマンスとNode.js互換性の向上

Bunは常にパフォーマンスを追求しており、v1.1でも例外ではありません。

• 高速化: Date.now()のような基本的なAPIの呼び出しがさらに高速化されたほか、Windows上でのファイルシステム操作（fs.readdirなど）はNode.jsより58%も高速であると報告されています。
• 互換性向上: node:httpやnode:vmといったNode.jsのコアモジュールとの互換性がさらに向上し、これまでBunでは動作しなかった多くのnpmパッケージが正しく動作するようになりました。

Node.jsからBun v1.1への実践的移行戦略

既存のNode.jsプロジェクトをBunに移行するのは、多くの場合驚くほど簡単です。

Step 1: 依存関係のインストール

プロジェクトのルートディレクトリで、npm installの代わりにbun installを実行します。

bun install

Bunはpackage-lock.jsonやyarn.lockを解釈できるため、既存のロックファイルから非常に高速に依存関係をインストールします。完了すると、Bun独自のロックファイルbun.lockbが生成されます。

Step 2: スクリプトの実行

package.jsonに定義されているスクリプトをnpm runの代わりにbun runで実行してみましょう。

# 例: 開発サーバーを起動する
bun run dev

多くのプロジェクトでは、これだけでアプリケーションが起動するはずです。

Step 3: コードの互換性対応

ほとんどのNode.jsコードはそのまま動作しますが、一部修正が必要な場合があります。最も一般的なのはパスの扱いです。

パスの扱い: Node.jsのCommonJSモジュールで使われる__dirnameや__filenameは、ESM（ECMAScript Modules）が標準のBunでは直接利用できません。代わりに、ESM標準のimport.meta.dirとimport.meta.fileを使用します。

// 修正前 (Node.js/CommonJS)
const path = require('path');
const filePath = path.join(__dirname, 'data.json');

// 修正後 (Bun/ESM)
import path from 'path';
const filePath = path.join(import.meta.dir, 'data.json');

Step 4: Dockerfileの最適化

Bunを使うと、Dockerfileもよりシンプルで効率的になります。

Node.jsの一般的なDockerfile:

FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "run", "start"]

Bun用に最適化したDockerfile:

# Bun公式の軽量イメージを使用
FROM oven/bun:1.1-slim
WORKDIR /app

# 依存関係のインストール
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile

# ソースコードのコピーと実行
COPY . .
CMD ["bun", "run", "start"]

Bunのイメージは非常に軽量で、bun installも高速なため、ビルド時間と最終的なイメージサイズの両方を削減できます。

ベンチマーク：Bun v1.1 vs Node.js

Bunの速さを体感するために、簡単なWebサーバーでパフォーマンスを比較してみましょう。

サーバーコード (server.js):

import { serve } from 'bun';

serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello, World!");
  },
});
console.log("Server running at http://localhost:3000");

（このコードはBun専用ですが、同様のExpressサーバーをNode.jsで用意して比較します）

ベンチマークの実行: HTTPベンチマークツールoha（brew install ohaなどでインストール可能）を使って、各サーバーに負荷をかけます。

# 1. Bunサーバーを起動
# bun run server.js

# 2. 別のターミナルでベンチマークを実行
oha http://localhost:3000

# --- 同様にNode.jsサーバーでも実行して比較 ---

環境にもよりますが、多くの場合、リクエスト/秒（RPS）でBunがNode.jsを数倍上回る結果が観測できるはずです。この圧倒的なパフォーマンスがBunの最大の魅力です。

まとめ

Bun v1.1は、単なるパフォーマンスアップデートにとどまりません。Windowsネイティブサポートと**bun shell**という2つの強力な新機能により、開発体験と実用性を劇的に向上させ、BunをあらゆるJavaScriptプロジェクトにおける現実的な選択肢へと押し上げました。

Node.jsからの移行パスは明確で、多くの場合、わずかな修正で大きなパフォーマンス向上という恩恵を受けられます。まだBunを試したことがない方も、このv1.1を機に、ぜひその速さと便利さを体験してみてください。