インストール - Bun
概要
Bunは、Oven Inc.のJarred Sumnerによって開発された、高速なJavaScript / TypeScriptランタイムである。
Zig言語で記述されており、JavaScriptCore (Safariのエンジン) を採用することにより、V8ベースのNode.jsより大幅に速い起動時間と低いメモリ使用量を実現している。
Bunの最大の特徴は、ランタイム・パッケージマネージャー・バンドラー・テストランナーの4つの機能を単一バイナリに統合している点である。
従来のJavaScriptエコシステムで必要だったNode.js + npm / Yarn + webpack / esbuild + Jestという複数ツールの組み合わせを、Bun単体で置き換えることができる。
Node.jsとの互換性を設計目標としており、fs、path、http 等の組み込みモジュールやnpmレジストリからのパッケージをそのまま利用できる。
TypeScriptおよびJSX / TSXはネイティブにサポートされており、追加のトランスパイラ設定なしで直接実行可能である。
プロジェクトの要件、チームの慣習、パフォーマンスの要求に応じて、npm・Yarn・pnpmとの使い分けを検討することが重要である。
Bun
Bunは公式インストールスクリプトによりひとつのコマンドでセットアップできる。
Linux上ではGLIBC 2.17以上の環境 (glibcビルド) と musl libc環境 (Alpine等) 向けに別のビルドが提供されている。
Bunのインストール
Bunには以下のインストール方法が存在する。
- 公式インストールスクリプトを使用したインストール (推奨)
- 最も簡単な方法であり、システムを自動検出して適切なバイナリをダウンロードする。
- 任意のディレクトリへのインストール
- 環境変数
BUN_INSTALLを指定することで、インストール先を自由に変更できる。
- 環境変数
環境や要件に応じて、適切なインストール方法を選択する。
前提条件の確認
インストールの前に、Linuxカーネルのバージョンとゲプロセッサーの機能拡張を確認する。
カーネルバージョンを確認する。
uname -r
カーネルバージョン5.6以上を推奨する。(最低要件は5.1)
5.1未満の環境ではBunは動作しない。
CPUのAVX2サポートを確認する。
grep -o 'avx2' /proc/cpuinfo | head -1
確認結果の解釈は以下の通りである。
- avx2 と表示される場合
- 標準ビルドを使用できる。
- 何も表示されない場合
- SSE4.2のみを必要とするベースラインビルドを使用する。
依存パッケージのインストール
インストールスクリプトの実行には unzip と curl が必要である。
# RHEL sudo dnf install unzip curl # SUSE sudo zypper install unzip curl
公式インストールスクリプトを使用したインストール
公式のcurlスクリプトを使用する方法が推奨される。
このスクリプトはシステムを自動検出して適切なバイナリをダウンロードし、デフォルトでは ~/.bun/ ディレクトリ内に配置する。
インストールスクリプトを実行する。
curl -fsSL https://bun.com/install | bash
インストール後のディレクトリ構成は以下の通りである。
~/.bun/
├── bin/
│ └── bun # 実行バイナリ
└── install/
└── cache/ # パッケージキャッシュ
CPUがAVX2に対応していない場合、"Illegal Instruction" エラーが発生することがある。
その場合は以下に示すコマンドを実行して、ベースラインビルドをインストールする。
curl -fsSL https://bun.com/install | bash -s -- --baseline
任意のディレクトリへのインストール
インストール先ディレクトリを変更したい場合は、環境変数 BUN_INSTALL を事前に設定することで実現できる。
この方法は公式インストールスクリプトが正式にサポートしている。
BUN_INSTALL に指定したパスの下に bin/ サブディレクトリが作成され、bunバイナリが配置される。
任意のディレクトリを指定してインストールスクリプトを実行する。
<sytaxhighlight lang="sh"> # 任意のディレクトリを指定して実行 export BUN_INSTALL="/opt/bun" curl -fsSL https://bun.com/install | bash # または1行で実行する場合 BUN_INSTALL="/opt/bun" curl -fsSL https://bun.com/install | bash </sytaxhighlight>
以下に代表的なインストール先の例を示す。
<sytaxhighlight lang="sh"> # ユーザ専用ディレクトリへのインストール例 BUN_INSTALL="$HOME/.local/bun" curl -fsSL https://bun.com/install | bash # システム共有ディレクトリへのインストール例 (root権限が必要) sudo BUN_INSTALL="/usr/local/bun" curl -fsSL https://bun.com/install | bash </<sytaxhighlight>
BUN_INSTALL はインストール時のみ参照される環境変数であり、インストール完了後はPATHの設定で同じディレクトリを指定することが必要である。
PATHの設定
インストールスクリプトは自動でPATHを追記するが、反映されない場合は手動で設定する。
# ~/.profileファイル等
# デフォルトディレクトリの場合
export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$PATH"
# 任意のディレクトリ (例:/opt/bun) を指定した場合
export BUN_INSTALL="/opt/bun"
export PATH="$BUN_INSTALL/bin:$PATH"
RHELでの注意
RHELでは、シェル設定の管理に ~/.bashrc.d/ ディレクトリが活用されている。
インストールスクリプトが ~/.bashrc を直接書き換えた場合、PATH設定が重複することがある。
そのため、設定を分離して管理することを推奨する。
# .bashrc.d ディレクトリを作成 (存在しない場合) mkdir -p ~/.bashrc.d
# ~/.bashrc.d/bun.sh ファイルを作成する
export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$PATH"
インストールが正常に完了したことを確認する。
# バージョン番号を表示 bun --version # 詳細なビルドリビジョンを表示 bun --revision
Bunの使用方法
Bunのコマンド構文はnpmやYarnと高い互換性を持ち、既存の package.json ファイルをそのまま利用できる。
新しいプロジェクトを初期化する時は、以下に示すコマンドを実行する。
# 対話形式でpackage.jsonを作成 bun init # デフォルト設定で初期化 bun init -y
package.json ファイルに記述された全ての依存関係をインストールする場合は、以下に示すコマンドを使用する。
# 全ての依存関係をインストール bun install ## または bun i
新しいパッケージを追加する場合は、以下に示すコマンドを使用する。
# 本番環境で必要な依存関係として追加 bun add <パッケージ名> # 開発環境でのみ必要な依存関係として追加 bun add --dev <パッケージ名> ## または bun add -D <パッケージ名> # 特定のバージョンを指定して追加 bun add <パッケージ名>@<バージョン> # グローバルにインストール bun add -g <パッケージ名>
インストールされているパッケージを更新する。
# 全てのパッケージを更新 bun update # 特定のパッケージを更新 bun update <パッケージ名>
パッケージを削除する。
bun remove <パッケージ名>
package.json ファイルに定義されているスクリプトを実行する。
bun run <スクリプト名> # 例: テストスクリプトを実行 bun test # 例: ビルドスクリプトを実行 bun run build
bun.lockbファイル
Bunは、bun.lockb ファイルというバイナリ形式のロックファイルを使用して依存関係のバージョンを固定する。
このファイルはnpmの package-lock.json や Yarnの yarn.lock に相当し、チーム全体で一貫した依存関係を保証するために重要である。
bun.lockb ファイルの特徴を以下に示す。
- インストールされた全てのパッケージの正確なバージョンを記録する。
- バイナリ形式のため、テキスト形式のロックファイルよりも解析が高速である。
- 異なる環境で同一の依存関係ツリーを再現できる。
bun.lockbファイルは自動生成されるため手動編集は不要であり、バージョン管理システムにコミットすることが推奨される。
テキスト形式で内容を確認する場合は以下のコマンドを使用する。
bun bun.lockb
Bunのキャッシュ管理
Bunは、ダウンロードしたパッケージをグローバルキャッシュに保存することにより、インストール速度を向上させている。
デフォルトのキャッシュパスは ~/.bun/install/cache であり、環境変数 BUN_INSTALL_CACHE_DIR で変更可能である。
キャッシュに関連する操作を以下に示す。
# キャッシュのパスを確認 echo $BUN_INSTALL_CACHE_DIR # キャッシュをクリア rm -rf ~/.bun/install/cache
bunfig.toml ファイルにキャッシュディレクトリを設定することもできる。
# bunfig.toml
[install.cache]
# キャッシュディレクトリのパス
dir = "~/.bun/install/cache"
# trueの場合、グローバルキャッシュを使用しない
disable = false
# trueの場合、常にレジストリから最新バージョンを解決する
disableManifest = false
Bunのアップデート
Bunは自身のコマンドでアップデートできる。
# 安定版の最新リリースへアップデート bun upgrade # canary (開発最新) ビルドへアップデート bun upgrade --canary # canaryから安定版に戻す bun upgrade --stable # 特定のバージョンを指定してインストール curl -fsSL https://bun.com/install | bash -s "bun-v1.x.y"
Bunのアンインストール
Bunはシステムへの影響が最小限であり、インストールディレクトリを削除するだけで完全にアンインストールできる。
# デフォルトインストールの場合 rm -rf ~/.bun # 任意ディレクトリへインストールした場合 (例:/opt/bun) rm -rf /opt/bun
合わせて、~/.profile、~/.bashrc.d/bun.sh、~/.zprofile 等に追記したPATH設定の行を手動で削除する。
パッケージマネージャーの比較
npm
npmは、Node.jsに標準で付属しており、追加のインストールが不要であることがメリットである。
また、最も広く使用されているため、ドキュメントとコミュニティサポートが充実している。
npm 7以降では、パフォーマンスが大幅に改善されており、ワークスペース機能もサポートされている。
Yarn
Yarnは、並列インストールによる高速化と、yarn.lock ファイルによる確実な依存関係の固定が特徴である。
Yarn Classicは、安定性と互換性を重視する場合に適している。
Yarn Berryは、Plug'n'Play機能により、高速化とディスク効率の向上が図られている。
ワークスペース機能がネイティブにサポートされており、モノレポ構成に適している。
pnpm
pnpmは、コンテンツアドレサブルストレージとハードリンクを使用することで、ディスク使用量を大幅に削減できる点が最大の特徴である。
また、厳密な依存関係の管理により、ゴーストディペンデンシーの問題を防ぐことができる。
ワークスペース機能も優れており、モノレポ構成の管理が効率的に行える。
Bun
Bunは、パッケージマネージャーとしても最速クラスの性能を発揮し、npmの最大30倍速いインストール速度が計測されている。
ランタイム・バンドラー・テストランナーを一体化しているため、ツールチェーンを大幅に簡素化できる。
Node.jsとの高い互換性を持つが、一部のネイティブアドオンパッケージでは互換性の問題が生じる場合があるため、事前の検証を推奨する。
一般的に、Bunが最も高速なインストール速度を提供して、次いでpnpm、Yarn、npmの順となる。
移行時の注意
既存プロジェクトのパッケージマネージャーを変更する場合は、以下に示す事柄に注意する。
- ロックファイルの違い
- npmは package-lock.json、Yarnは yarn.lock、pnpmは pnpm-lock.yaml、Bunは bun.lockb を使用する。
- パッケージマネージャーを変更する場合は、古いロックファイルを削除して、新しいロックファイルを生成する必要がある。
- 統一されたツールを使用すること
- 異なるパッケージマネージャーを混在させると、ロックファイルの不整合が発生する可能性がある。
- package.json の
packageManagerフィールドに使用するツールを明記することを推奨する。
- CI/CD環境の設定を更新する
- 各パッケージマネージャーに応じて、インストールコマンドとキャッシュの設定を適切に構成する必要がある。