pnpm vs bun install 比較

コンテンツアドレス指定ストア、厳格な分離、成熟したサプライチェーン監査

VS
bun install

Rustコア、高速、Bunランタイムのオールインワン型インストールコンポーネント

16 分で読了ツール

クイック結論

明確な勝者はいない。2つのツールは異なる優先事項に最適化されている。ランタイムに依存せず、ロックファイルを変更するすべてのコマンドでポリシーを監査したいならpnpmを選ぶべきだ。すでにBunをランタイムとして使っていて、グローバル仮想ストアによるディスク/速度の向上が重要ならbun installが魅力的だ。どちらもpostinstallをデフォルトでブロックする——違いは監査ポイントの置き場所にある。同じリポジトリで両者を混在させてはいけない。ロックファイルは1つ、信頼できる情報源も1つに保つべきだ。

pnpmbun install
結論をすべて読む

スコア比較

グラフを読み込み中...

詳細スコア

詳細スコア: pnpm と bun install — カテゴリー別10点満点のスコア
カテゴリーpnpmbun install
パフォーマンス
8/10
9/10
学習のしやすさ
7/10
8/10
エコシステム
9/10
6/10
コミュニティ
8/10
7/10
求人市場
7/10
6/10
将来性
8/10
8/10

長所と短所

pnpm

長所

  • コンテンツアドレス指定ストアのおかげで、同じパッケージバージョンはディスク上に1コピーだけ保持され、ディスク使用量が減る
  • 厳格なnode_modules構造により、追加設定なしでデフォルトでphantom dependencyを防止する
  • 12.2〜12.3で--trust-lockfile/--trust-policyがremoveとupdateコマンドでも強制できるようになった
  • allowBuildsアローリストにより、postinstallスクリプトが明示的で監査可能なリストに紐づく(pnpm 10ではonlyBuiltDependencies、v11以降はallowBuilds)
  • Turborepo、Nx、Changesetsとの長年にわたり成熟したワークスペース統合
  • Node.js上で動作するためランタイム選択から独立しており、プロジェクトを単一のツールにロックインしない
  • catalog:フィールドにより、モノレポ全体で共通の依存バージョンを一元管理できる
  • 12.x以降コアがRustに書き直され、ワークスペース探索とロックファイルのパースが並列に実行される

短所

  • シンボリックリンクベースのnode_modules構造は、一部の古い/単純なNodeツール(厳密でない解決を前提とするもの)との非互換を引き起こすことがある
  • allowBuildsアローリストを手動で埋める必要があり、ネイティブビルドを必要とする新しいパッケージを追加するたびに追加の手順が発生する
  • Bunが公開する速度ベンチマークは自社のリンカー同士の比較であり、このスケールでのpnpmの位置づけを知るには自分のリポジトリで実測する必要がある
  • 独自のランタイムを持たない——インストール+実行+テストが単一ツールから提供される統合体験は得られない
  • ストアをCIキャッシュ戦略に正しく組み込む(pnpm store path)には手動のセットアップ手順が必要になる

最適な用途

Node.js本番環境を持ち、ランタイムに依存しない状態を保ちたいチームTurborepoまたはNxでオーケストレーションされる大規模モノレポロックファイルを変更するすべてのコマンドでサプライチェーンポリシーを監査したい規制対象プロジェクトディスク容量が限られたCIランナー、または類似プロジェクトを多数抱える組織既存のnpm/Yarnプロジェクトから低リスクで段階的な移行を求めるチーム

bun install

長所

  • Bun 1.4のオプトイン型グローバル仮想ストアは、--linker=isolatedモードでインストールを大幅に高速化する
  • postinstallスクリプトはデフォルトでブロックされ、trustedDependenciesアローリストがサプライチェーンを明示的に監査する
  • --offlineおよび--prefer-offlineフラグにより、CI/エアギャップ環境のインストールシナリオを明確に表現できる
  • isolated installsモードは、pnpmに似たアプローチでphantom dependencyをアーキテクチャレベルで防止する
  • テキストベースのロックファイル形式bun.lock(v1.2+でデフォルト)は、PRレビューで可読性のあるdiffを生成する
  • インストール・ランタイム・テストランナーが単一ツールから提供されるため、グリーンフィールドのBunプロジェクトで統合された体験を提供する
  • bun install --filterによるワークスペース単位のインストールフィルタリングがネイティブでサポートされている

短所

  • グローバル仮想ストアはデフォルトで無効で、isolatedリンカーでのみ動作する。効果を得るにはbunfig.tomlで明示的に有効化する必要がある
  • isolatedリンカーは新規のワークスペース/モノレポプロジェクト(configVersion = 1)でのみデフォルトであり、単一パッケージプロジェクトやv1.3.2以前の既存プロジェクトではデフォルトがhoistedのままなため、phantom dependencyのリスクは手動で塞ぐ必要がある
  • Turborepo/Nxなどのツールとの統合は、pnpmのそれと比べて成熟の歴史が短い
  • Bunの組み込みtrustedDependenciesデフォルトアローリストはnpm由来のパッケージのみをカバーしており、file:/link:/git:/github:の依存関係は手動で追加する必要がある
  • インストールツールがBunランタイムの一部であるため、別のJSランタイムへの移行を望むチームにとってはツール依存が生じる
  • 古いバイナリ形式のbun.lockbから新しいテキストベースのbun.lockへの移行は、既存プロジェクトで追加のマイグレーション手順を必要とする

最適な用途

すでにBunランタイムを本番環境で使用しているチームインストール速度とCIキャッシュ制御が重要なグリーンフィールドプロジェクトオフライン/エアギャップ環境のCIで明確なフラグ制御を求めるチーム単一ツールでインストール+実行+テストを完結させたい、小〜中規模のBun専用プロジェクト

コード比較

pnpm
// pnpm 12.3 — allowBuildsによる監査可能なインストールとワークスペースフィルタリング
// package.json (ルート)
{
  "name": "monorepo-root",
  "private": true,
  "packageManager": "[email protected]"
}

// pnpm-workspace.yaml — allowBuilds は v10.26.0 で導入、v11 で旧名称(onlyBuiltDependencies など)が削除された
packages:
  - "apps/*"
  - "packages/*"

allowBuilds:
  esbuild: true
  sharp: true
  core-js: false

catalog:
  react: ^19.2.3
  typescript: ^5.7.0

// CIインストールステップ (GitHub Actions)
- name: Install dependencies
  run: pnpm install --frozen-lockfile --trust-policy=no-downgrade

// パッケージを削除する際、ロックファイル全体がアクティブなポリシーに対して再検証される
pnpm remove left-pad --filter ./apps/web --trust-lockfile

// 変更されたワークスペースパッケージのみにインストール
pnpm install --filter "...[origin/main]"

// ストアの場所をCIキャッシュキーに追加する
pnpm store path
bun install
// Bun 1.4 — isolated installs + グローバル仮想ストア + オフラインインストール
// bunfig.toml (ルート)
[install]
linker = "isolated"
globalStore = true
exact = false

// package.json
{
  "name": "monorepo-root",
  "private": true,
  "workspaces": ["apps/*", "packages/*"],
  "trustedDependencies": [
    "esbuild",
    "sharp",
    "@prisma/client"
  ]
}

// CIインストールステップ (GitHub Actions) — ロック済みかつオフライン対応
- name: Install dependencies
  run: bun install --frozen-lockfile --prefer-offline

// ブロックされたpostinstallスクリプトを確認する
bun pm untrusted

// パッケージを信頼済みとしてマークする
bun pm trust sharp

// 特定のワークスペースパッケージにインストール
bun install --filter "./apps/web"

// 完全オフラインインストール(ネットワークに一切出ない)
bun install --offline

結論

明確な勝者はいない。2つのツールは異なる優先事項に最適化されている。ランタイムに依存せず、ロックファイルを変更するすべてのコマンドでポリシーを監査したいならpnpmを選ぶべきだ。すでにBunをランタイムとして使っていて、グローバル仮想ストアによるディスク/速度の向上が重要ならbun installが魅力的だ。どちらもpostinstallをデフォルトでブロックする——違いは監査ポイントの置き場所にある。同じリポジトリで両者を混在させてはいけない。ロックファイルは1つ、信頼できる情報源も1つに保つべきだ。

無料相談を受ける
FAQ

よくある質問

シナリオによって異なる。Bunが公開しているベンチマークは自社のリンカー同士の比較で、1,400パッケージのReact/webpack/Babel/jestフィクスチャでは、ホットインストールがhoistedリンカーで823.9ms、isolatedリンカー+グローバルストアで124.8ms(Apple Silicon macOS、hyperfine)。pnpmのコンテンツアドレス指定ストアもホットインストール時にディスク読み取りに依存するため、どちらも適切な条件下では高速だ。2つのツール間の差は自分のリポジトリサイズとCIキャッシュ戦略で測定すべきであり、単一のフィクスチャ結果を自分のモノレポにそのまま当てはめてはいけない。

関連ブログ記事

すべての記事を見る
すべての比較