bun

Bun

Bun ランタイム、パッケージマネージャー、テストランナー、バンドラー、bunfig.toml、Node 互換性、またはインストールやスクリプトの Bun への移行に関わる作業では、このスキルを使用してください。

スナップショット：[email protected]、@types/[email protected] / [email protected]（2026-09-18 に取得、2026-10-01 に再確認済み — 引き続き最新の安定版です）。バージョンが異なる場合は、source-map.md を参照して更新してください。

ワークフロー

1. ローカルの Bun 環境を確認します。
   • bun --version / bun --revision（安定版の系列は 1.4.x です。API が重要な場合は、1.4.2 へのアップグレードに bun upgrade を使用してください）。
   • ロックファイル：bun.lock（テキスト形式。lockfileVersion は 2、またはネストされた／バージョン指定のオーバーライドを使う場合は 3）と、旧形式の bun.lockb。
   • package.json のスクリプト、ワークスペース、カタログ、オーバーライド、trustedDependencies、任意の nativeDependencies / ignoreScripts / selfContained。
   • bunfig.toml（プロジェクト用と任意のグローバル設定）、.npmrc、@types/bun、TypeScript 6/7 の "types": ["bun"]。
   • コードが Bun ネイティブ API（Bun.serve、Bun.Image、bun:sqlite、…）と Node API（node:*）のどちらを使っているか。
2. 日常的な使い方、段階的な導入、トラブルシューティングについては、まず usage-guide.md を参照してください。
3. バージョンに差異がある場合、または Redis/SQL/HTTP2/HTTP3/FFI、ロックファイル／リンカー／globalStore、あるいは 1.3→1.4 のアップグレードに関わる場合は、ドキュメントを更新してください。source-map.md から始めてください。
4. 詳細情報の参照先：
   • ランタイム API、HTTP、ファイル、シェル、Image/WebView/markdown/cron、SQLite/Redis/S3/SQL：runtime-apis.md。
   • インストール、ロックファイル、ワークスペース、信頼設定、bunx、CI、audit/dedupe/prune：package-manager.md。
   • bun test、bun build、--compile、init/create：test-bundler-build.md。
   • Node 26 互換性、グローバル、watch/hot、bunfig、1.3→1.4 の破壊的変更：node-compat-config.md。
5. 新規に Bun プロジェクトを作成する場合は、Bun ネイティブ API と bun / bunx コマンドを優先してください。コードベースがすでに Node の構成で、問題なく動作している場合は、Node API を引き続き使用してください。
6. 最も適切な範囲に絞った bun コマンド（bun test、bun run、bun ci、または対象を絞った Bun.serve のスモークテスト）で検証してください。

基本的な判断

• Bun は 1 つのバイナリにまとまった ランタイム + パッケージマネージャー + テストランナー + バンドラー であり、「単に Node を高速化したもの」ではありません。1.4 では、このバイナリが Rust で書き直され、標準ライブラリが拡充されています（Image、WebView、markdown、cron、Terminal、XML/JSON5/JSONL）。
• Bun プロジェクトのコマンドでは、npm / npx / yarn / pnpm より bun / bunx を優先してください。
• bun.lock をコミットしてください。CI でのインストールには bun ci（ロックファイルを固定）を使用してください。
• 依存パッケージのライフサイクルスクリプトは、信頼済みでない限りデフォルトでブロックされます。ネイティブパッケージ（sharp など）を追加した後は bun pm untrusted を確認してください。
• 新しいワークスペースのロックファイルでは、リンカーはデフォルトで isolated（configVersion: 1）です。旧形式のロックファイルでは hoisted のままです。グローバル仮想ストアはオプトイン方式（[install] globalStore = true）で、isolated にのみ適用されます。
• 新しい HTTP サービスには Bun.serve を優先してください。デフォルトのアイドルタイムアウトは 10 秒です（SSE では server.timeout(req, 0) が必要です）。HTTP/2（http2: true）と HTTP/3（http3: true）は実験的機能です。
• Bun を第一に使うコードでは、重い Node クライアントより bun:sqlite / Bun.SQL / Bun.redis / Bun.Image を優先してください。
• bun --watch はハードリスタートし、bun --hot はソフトリロードします（globalThis は維持されます）。サーバーに適しています。
• Bun のフラグは run より前に指定します。bun run dev --watch ではなく、bun --watch run dev とします。
• Bun.env は起動時点のスナップショットです。実行中に値が変わる場合は process.env を優先してください。
• bun build は型チェックを行わず、.d.ts も出力しません。型が重要な場合は tsc を実行してください。
• 1.4 では bun:ffi はエンジンネイティブです（cstring は通常の文字列です）。本番環境で重要な FFI には Node-API のネイティブアドオンを優先してください。
• 1.3→1.4：Bun が報告する Node.js のバージョンは 26 です（process.versions.modules は 147）。bunfig.toml の文字列は引用符で囲む必要があります。全変更の一覧：node-compat-config.md。

検証

リポジトリで定義されているコマンドを優先してください。重要な Bun の作業では、関連する項目を実施してください。

• bun --version を実行し、ロックファイル、リンカー、globalStore の想定を確認します。
• 対象を絞った bun test（パスまたは -t パターン）を実行します。CI で必要な場合は、--parallel、カバレッジ、JUnit も使用します。
• ロックファイルを編集した後は、bun ci または bun install --frozen-lockfile を実行します。
• bun run <entry>、または port: 0 と fetch を使った Bun.serve でスモークテストを実行します。
• ネイティブ依存関係を追加した後は、必要に応じて bun pm untrusted を実行し、信頼する依存関係を設定します。
• bun build または --compile の後は、対象プラットフォームで出力を実行します。
• Node 互換性の移行では、Bun で同じテストスイートを実行し、一部対応のモジュールを記録します。
• 1.3 から 1.4 に更新した後は、NODE_MODULE_VERSION 147 用にネイティブアドオンを再ビルドし、bunfig.toml を引用符で囲み、res.writeHeader() を使用しないようにします。

実施した確認と実施しなかった確認、および残っている Bun のバージョンに関する前提を報告してください。