package.json，並在自己的輸出裡印出 Bun 指令。
從 Extension.js 4.1.21 開始，CLI 也能跑在 Bun 上，需要 Bun 1.2 或更新版本。下面那個問題分成兩半，而它們的答案已經和以前不一樣了。
我可以用 Bun 取代 Node 嗎？
對你的專案而言可以，對 CLI 行程而言也可以。
單純的
bunx extension 仍然會把 CLI 跑在 Node 上，因為發佈出去的執行檔帶著 #!/usr/bin/env node 這行 shebang。加上 --bun，或者在 bunfig.toml 裡設定 run.bun，才會在 Bun 上執行。
用 Bun 建立專案
package.json 會固定住你所使用的管理器：
package.json
安裝與建置
bun.lock 檔案。之後每次執行，Extension.js 都會讀取這份 lockfile，以便繼續選擇 Bun。
extension 這個執行檔，所以 bun run dev、bun run build 與 bun run preview 都能用。
哪些 Bun 版本可用
Extension.js 需要 Bun 1.2 或更新版本。CLI 在啟動時讀取process.versions.bun，依 Bun 自己的版本來判斷，而不是依 Bun 回報的 Node 版本，因為這兩者並不同步：Bun 1.1.38 與 Bun 1.2.0 都回報 Node 22.6.0，但只有其中一個能跑完建置。
低於 1.2 的 Bun 無法載入 rspack 的原生綁定，所以舊版本不是在門口被擋下，而是在打包器深處失敗。防護會先把它擋住：
process.versions.bun 辨識的，這個值由執行階段自己設定，所以進入 Bun 的每一條路徑都被涵蓋：bunx 與 bun run 上的 --bun 旗標，以及 bunfig.toml 裡的 run.bun 預設值。
Extension.js 如何偵測 Bun
偵測讀的是專案，而不是你敲下的那條指令。有三個訊號餵給它：- 專案根目錄下的
bun.lock或bun.lockblockfile。 package.json裡點名bun的packageManager欄位。- Bun 執行 script 時所設定的
npm_config_user_agent環境變數。
npm、pnpm、yarn、bun 與 deno。當一個訊號都沒有時，它會依 pnpm、yarn、bun 的順序探測你的 PATH。
自動安裝相依套件
extension dev 與 extension build 會在編譯之前先裝上缺少的相依套件。這次安裝走的是被偵測到的那個管理器，而且會傳入 --ignore-scripts。因此相依套件裡的 postinstall script 不會在這一步執行。
注意事項
Bun.file這類 Bun 專有的執行階段 API 不屬於擴充功能程式碼。那些程式碼是跑在瀏覽器裡的。- Extension.js 不會寫任何 Bun 專有的 scripts。
dev、build與previewscripts 對每個管理器都一樣。 - 你透過
extension create引入的範本不帶 lockfile。Extension.js 會從中剝掉bun.lock與bun.lockb。之後由你自己那次安裝決定相依樹。
下一步
- 與 Deno 設定做個比較。
- 了解 Extension.js 如何處理 Node API。
- 進一步了解如何管理 extension 設定。