npm vs Yarn vs pnpm vs Bun：2026 完整比較

2026 年，你有四個實力堅強的選擇可以用來管理 JavaScript 相依性，而它們之間的差距從未如此之大。npm 11 帶來了 min-release-age 與 npm trust，強化供應鏈安全。pnpm 10 預設將生命周期腳本改為手動啟用。Yarn 4 讓其 Plug'n'Play 引擎與基於 JS 的 constraints 機制更加成熟。Bun 1.3 則加入了相依性 catalog、bun why 與互動式更新。在 2026 年挑選最佳 node 套件管理器，已經不再是「npm 很慢，換個試試」這麼簡單，而是要為你的專案匹配最合適的架構。

這篇 JavaScript 套件管理器比較文章，提供的是多數指南略而不談的內容：在明確硬體規格上的實際安裝速度基準測試、涵蓋每種工作流程的並列程式碼範例、真實的 CI/CD 管線數據，以及一套具體的決策框架。根據我們用這四款工具打造生產環境應用程式的經驗，讀完之後，你將清楚知道自己該選哪一個。

快速摘要：npm vs Yarn vs pnpm vs Bun 一次看懂

在深入細節之前，先講結論。

選 pnpm，如果你想要在速度、正確性與 monorepo 工具之間取得最佳整體平衡。選 Bun，如果極致的安裝速度與一體化的執行環境是你的優先考量。選 npm，如果你想在簡單專案上零設定開箱即用。選 Yarn Berry，如果你的團隊已經深度投入 Plug'n'Play 與 zero-installs。

現在，讓我們逐一拆解，看看每款工具為何獲得這些評價。

參賽者：快速介紹

npm，預設選擇

npm 隨每個 Node.js 安裝一併提供。與其說你選擇了它，不如說你繼承了它。第 11 版帶來了有意義的安全改進：min-release-age 讓你拒絕發布未滿 X 天的套件（降低 typosquatting 風險），而 npm trust 則針對經驗證的發布者提供逐指令的設定。它仍然是其他所有工具被拿來比較的基準，而對小型專案來說，它運作得相當好。

Yarn，Classic 與 Berry 之別

Yarn 由 Facebook 於 2016 年建立，目的是解決 npm 早期的可靠性問題。這裡有個關鍵區別：**Yarn Classic (1.x) 已進入維護模式。**不要用展開新專案。Yarn Berry（2+，現為 v4） 才是現代版本，而且它是一個根本不同的工具。它的招牌功能是 Plug'n'Play (PnP)，徹底取消 node_modules，改以 .pnp.cjs 檔案直接對應 import。Yarn 4 還包含一個基於 JS 的 constraints 引擎，用於在 monorepo 各套件間強制執行規則，以及自動化的 @types 管理。

pnpm，效率專家

pnpm 是「performant npm」的縮寫，而它名副其實。它的內容可定址全域 store 在你的磁碟上為每個套件版本只保留一份副本，然後以硬連結接入每個專案的 node_modules。結果就是：嚴格的相依性解析，防止幻影相依性（phantom dependencies）、節省 50-70% 磁碟空間，以及比 npm 更快的安裝速度。第 10 版做了一個大膽的決定——生命周期腳本現在預設停用，改以 onlyBuiltDependencies 允許清單管理。你必須明確選擇啟用，才會執行 postinstall 腳本。

Bun，一體化執行環境

Bun 不只是一個套件管理器。它以 Zig 打造，擁有原生級效能，將 JavaScript 執行環境、打包器、測試執行器與套件管理器合而為一。1.3 版帶來了相依性 catalog（用於 monorepo 的集中式版本管理）、bun why（追蹤某個套件為何被安裝）以及互動式 bun update。它的安裝速度確實驚人——我們很快就會看到實際數字。

安裝與設定

每款工具的上手方式各不相同：

# npm -- ships with Node.js, nothing to install
npm --version

# Yarn -- use Corepack (recommended)
corepack enable
yarn init -2

# pnpm -- use Corepack or standalone install
corepack enable
pnpm --version
# or: npm install -g pnpm

# Bun -- standalone install
curl -fsSL https://bun.sh/install | bash
# or: brew install oven-sh/bun/bun

Corepack：管理套件管理器的官方方式

這裡有個多數指南會略過的重點：Corepack 內建於 Node.js（自 v16.9 起），它解決了套件管理器的「在我電腦上可以跑」問題。只要在你的 package.json 加上一個 packageManager 欄位，團隊裡的每個開發者就會自動使用完全相同的版本：

{
  "name": "my-project",
  "packageManager": "[email protected]",
  "engines": {
    "node": ">=22.0.0"
  }
}

執行一次 corepack enable，Corepack 就會攔截 pnpm 或 yarn 指令，下載並使用你釘選的版本。不用管理全域安裝，團隊間也不會有版本漂移。Bun 目前還不支援 Corepack，你需要透過其他方式釘選它的版本（例如 .tool-versions 檔案或 CI 設定）。

CLI 指令對照

這張表對照了四款管理器的等效指令。把它加入書籤，你會再三回來看。

有幾點值得注意：Bun 使用 bun add 而非 bun install <pkg>，而且你可以只用 bun dev 執行腳本（run 可省略）。pnpm 和 Yarn 也讓你免用 run 關鍵字就能執行腳本。npx/pnpx/yarn dlx/bunx 的差異常讓不少開發者踩坑，所以把這張表放在手邊吧。

安裝速度基準測試：npm vs pnpm vs Yarn vs Bun

這正是多數人想看的地方。我們彙整了多個來源的基準數據，這些測試在 Apple Silicon 硬體上以 2026 年的當前版本執行。以下是兩種專案規模下的冷安裝時間（無快取、無 lockfile）：

圖表一眼就能說明問題：相較於 npm 高達 14.3 秒的安裝時間，Bun 的長條幾乎看不見。pnpm 和 Yarn 落在中間，但兩者都追不上 Bun 不到一秒的冷安裝。專案越大，差距越懸殊——我們來看看完整的基準數字。

基準來源：Pockit（2026 年 1 月），M3 MacBook Pro，Node.js 22.x。並與 pnpm.io benchmarks（2026 年 2 月 8 日）及 edbzn/package-manager-benchmarks 交叉比對。

這些數字說了一個清楚的故事。Bun 在 0.8 秒內安裝完一個 50 個相依性的專案——比 npm 快 17 倍，比 pnpm 快 5 倍。在一個有 800 個相依性的大型 monorepo 上，Bun 在 4.8 秒內完成，而 npm 還在 134 秒苦苦掙扎。

為什麼 Bun 這麼快？三個原因：它用 Zig 撰寫（編譯後的原生碼，而非 JavaScript）、一次典型安裝大約只用 165,000 次系統呼叫，相較於 npm 的 1,000,000 次以上，而且它的二進位 lockfile（bun.lock）解析速度比 JSON 或 YAML 更快。

**結論：Bun 在原始速度上獲勝。**就冷安裝而言，Bun 比 pnpm 快 3-5 倍，比 npm 快 10-17 倍。pnpm 是穩居第二的強者。Yarn Berry 搭配 PnP 則完全繞過了這個問題——因為它取消了 node_modules，如果你提交快取（zero-installs），那就根本沒有東西需要安裝。

磁碟用量與儲存效率

速度不是一切。如果你同時在做多個 Node.js 專案，磁碟用量會迅速累積。以下是每款管理器儲存相依性的位置，以及它花費的空間：

Bun 和 Yarn PnP 在圖表底部並駕齊驅，相較於 npm 各自節省了超過一半的磁碟空間。pnpm 在單一專案的基礎上落在中段，但它真正的優勢會在多個專案之間顯現——正如我們在下表看到的。

數據來自 DevelopersVoice 基準測試與 Pockit 分析（2025-2026）。實際數字因專案而異。

單一專案的數字很有趣，但真正的故事出現在多個專案之間。把 pnpm 的 store 想像成一座共享圖書館：與其讓每個專案都擁有每本書的獨立副本，不如讓它們共用同一張借書證。如果你有 10 個 Node.js 專案都用 npm，你可能有 5 GB 的重複套件。改用 pnpm，這會降到約 1.5 GB，因為全域 store 會將一切去重。

Yarn Berry PnP 走的是另一條路——它徹底取消 node_modules。一個 .pnp.cjs 檔案將每個 import 對應到它在快取中的確切位置。搭配 zero-installs，你把快取提交到 repo，這樣 clone 就意味著零安裝時間。

Bun 的單一專案數字看起來不錯，但它不像 pnpm 那樣在專案之間共享套件。在 10 個專案的規模下，pnpm 的節省會急遽複利成長。

**結論：pnpm 在磁碟效率上以壓倒性優勢獲勝。**如果你願意走 zero-install 路線，Yarn Berry PnP 緊追在後。npm 和 Bun 都沒有針對跨專案去重做最佳化。

相依性解析深度剖析

上面的速度與磁碟數字並非偶然——它們是每款工具如何解析與儲存相依性的直接結果。理解架構，能幫助你預判自己正在做出哪些取捨。

npm：提升問題

npm 使用扁平提升（flat hoisting）。它把你所有的相依性，以及它們的相依性，全部安裝進單一一個頂層 node_modules 資料夾。這造成了一個叫做**幻影相依性（phantom dependencies）**的問題：即使你從未把 lodash 加進 package.json，你的程式碼依然可以 import 'lodash'，只因為另一個套件把它拉了進來，而 npm 將它提升到了頂層。

這運作得很好……直到某個傳遞相依性的更新移除了 lodash。你的程式碼在生產環境毫無預警地崩潰，因為你一直依賴一個從未明確安裝的套件。

Yarn Berry：再見 node_modules

Yarn Berry 的 Plug'n'Play 走的是最激進的路線。完全沒有 node_modules。一個 .pnp.cjs 檔案包含每個套件到其確切磁碟位置的對應。這意味著更快的查找（無需檔案系統遍歷）、沒有提升問題，以及 zero-installs 的選項。

代價呢？有些套件假設 node_modules 存在。如果你遇到相容性問題，可以在 .yarnrc.yml 用 nodeLinker: node-modules 退回舊制。但那樣就放棄了 PnP 的好處。

pnpm：以嚴格為設計

pnpm 走的是中間路線。它建立一個 node_modules 目錄（所以工具相容性很高），但結構根本不同。套件存放在 node_modules/.pnpm，再以符號連結接入定位。只有你在 package.json 明確宣告的套件，才能在頂層存取。

這意味著沒有幻影相依性。如果你沒把它加進 package.json，你就無法 import 它。你的程式碼會在開發階段快速失敗，而不是在三個月後的生產環境神秘崩潰。

Bun：快但扁平

Bun 使用和 npm 相同的扁平提升策略。它沒有解決幻影相依性——它把原始速度置於正確性之上。如果你從 npm 遷移過來，這意味著 Bun 在安裝上是隨插即用的替代品，但你也繼承了相同的相依性解析風險。

**結論：pnpm 在相依性正確性上獲勝。**它的嚴格解析能捕捉到 npm 和 Bun 默默掩蓋的真實 bug。Yarn Berry PnP 更嚴格，但需要更多的生態系相容性工夫。如果相依性正確性對你的團隊很重要（它本來就該重要），pnpm 是務實的選擇。

Monorepo 與 Workspace 支援

如果你在單一倉庫中管理多個套件，workspace 支援是一個關鍵的決策因素。以下是每款工具如何設定 monorepo：

// npm and Bun: package.json
{
  "workspaces": ["packages/*", "apps/*"]
}

# pnpm: pnpm-workspace.yaml
packages:
  - "packages/*"
  - "apps/*"

# Yarn Berry: package.json workspaces field
# plus .yarnrc.yml for constraints
enableGlobalCache: false
nodeLinker: pnp

Workspace 功能比較

pnpm 的過濾功能最為成熟。你可以依名稱、目錄或相依性圖，針對特定套件執行指令：pnpm --filter @app/web... build 會為某個套件及其所有相依性執行建置。Yarn 4 的 JS constraints 引擎獨一無二——你撰寫 JavaScript 規則，在整個 monorepo 強制執行政策（例如「所有套件都必須使用相同版本的 React」）。

Monorepo 中的 pnpm vs Yarn 歸結為理念之別。pnpm 透過嚴格的相依性模型強制正確性；Yarn 則透過 constraints 引擎強制。兩者都可行。pnpm 的做法需要較少設定。

**結論：pnpm 在 monorepo 工作流程上獲勝。**它的過濾、嚴格相依性解析與 workspace 協定支援最為成熟。Yarn Berry 以其獨特的 constraints 引擎穩居第二。npm workspaces 可用，但缺乏進階功能。Bun 正以 v1.3 的相依性 catalog 快速追趕。

安全性比較

針對 npm 套件的供應鏈攻擊是真實且日益嚴重的威脅。以下是每款工具如何保護你：

最大的差異點在於 postinstall 腳本的處理。當你執行 npm install，npm 預設會執行每個套件的所有生命周期腳本（install、postinstall、prepare）。這意味著一個被入侵的套件，能在你安裝它的那一刻，在你的機器上執行任意程式碼。

pnpm 10 和 Bun 翻轉了這個預設。除非你在 onlyBuiltDependencies（pnpm）或 trustedDependencies（Bun）明確將套件加入允許清單，否則腳本會被封鎖。這是一個根本性的安全改進。npm 11 的 min-release-age 是個聰明的補充——你可以拒絕最近 N 天內發布的套件，縮小 typosquatting 攻擊的窗口，但它是選擇啟用，而非預設。

**結論：pnpm 與 Bun 在安全性上領先。**兩者都預設封鎖生命周期腳本，這是對抗供應鏈攻擊最具影響力的單一防護。npm 11 的 min-release-age 是個聰明的補充，但屬於選擇啟用。Yarn 很彈性，但需要手動設定。

CI/CD 與建置效能

套件管理器的選擇直接影響你的 CI/CD 管線成本。更快的安裝意味著更短的建置，也就是更低的基礎設施帳單。以下是 GitHub Actions 的基準數據：

相較於 npm，Bun 為每個 GitHub Actions 作業省下了 42 秒——當你一天要跑數十次建置時，這是個有意義的差距。pnpm 落在中段，大約比 npm 快 26 秒。以下是包含安裝步驟在內的完整拆解。

來源：Pockit GitHub Actions 基準測試（2026 年 1 月）。標準 Node.js 建置 + 測試管線。

每款管理器在 CI 中都有不同的快取策略。以下是適用於 GitHub Actions 的生產級 pnpm 設定：

# .github/workflows/ci.yml
- uses: pnpm/action-setup@v4
  with:
    version: 10

- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'pnpm'

- run: pnpm install --frozen-lockfile
- run: pnpm build
- run: pnpm test

至於 Docker 最佳化，關鍵在於層快取：在原始碼之前先複製你的 lockfile，讓相依性安裝能跨建置快取。這適用於全部四款管理器。

現在來談錢。如果你的團隊每天跑 50 次 CI 建置，而從 npm 切換到 pnpm 每次建置省下 26 秒，那就是每天省下 21.6 分鐘。一個月下來，就是 10.8 小時的 CI 時間。以典型的 GitHub Actions 定價（Linux runner 每分鐘 $0.008）計算，大約是 每月 $5.18——對小團隊來說不算什麼，但對跑數百次建置的組織而言，節省會線性放大。真正的贏家是開發者的時間：更快的回饋迴圈意味著更高的生產力。

想深入了解部署平台如何衡量建置效率，套件管理器的選擇是你能拉動的最大槓桿之一。

**結論：Bun 在 CI 中最快。**但 pnpm 在速度、快取與生態系相容性之間提供了最佳平衡。真正的節省來自 CI 管線中更快的安裝，尤其是在規模化時。

框架相容性

你不會在真空中挑選套件管理器——你是為特定的框架與專案挑選它。以下是實際可行的方案，以及框架維護者的推薦：

好消息是：每個現代框架都能與四款管理器協作。細微之處在於 Bun 相容性與 Yarn PnP。

Bun 宣稱 98% 的 npm 相容性。剩下的 2% 包含某些使用 node-gyp 的原生模組、某些假設 npm 行為的 postinstall 腳本，以及 peer dependency 解析的邊緣案例。在投入之前，請針對你的特定專案進行測試。

Yarn PnP 有更廣泛的相容性問題。有些套件假設磁碟上存在 node_modules。如果你遇到問題，可以在 .yarnrc.yml 設定 nodeLinker: node-modules 作為退路，但那樣就放棄了 PnP 的好處。

當你在思考建置工具的選擇時，套件管理器只是其中一塊拼圖。但它是你每天會互動數十次的那一塊，所以值得把它弄對。

結論：npm 相容性最佳（它是通用的預設）。pnpm 緊居第二，對標準專案而言實際上沒有相容性問題。Bun 適用於 98% 的情況。Yarn PnP 需要相容性測試。

Bun 的生產就緒度：2026 現實檢視

每篇文章要嘛把 Bun 吹捧為未來，要嘛把它貶為太不成熟。以下是我們的誠實評估。

2026 年運作良好的部分：

• bun install 與大多數 npm 專案隨插即用。你不需要切換執行環境，只要把 Bun 當作搭配 Node.js 的套件管理器使用
• 二進位 lockfile（bun.lockb）已被文字格式的 bun.lock 取代，以利更好的 git diff
• 相依性 catalog 與 bun why 讓它更接近 pnpm 水準的 monorepo 工具
• Anthropic 將 Bun 用於 Claude Code 工具。其他知名公司也已採用它於內部工具

已知的邊緣案例：

• 使用 node-gyp 的原生模組可能失敗
• 某些 postinstall 腳本假設 npm 特有的行為
• Windows 支援較新，歷經的實戰考驗不如 Linux/macOS
• peer dependency 解析偶爾與 npm 有差異
• 某些 CI 環境需要明確安裝 Bun（它不像 npm 那樣預裝）

**務實的採用路徑：**你可以使用 bun install 而不切換到 Bun 執行環境。這是取得 Bun 速度優勢風險最低的方式。你的程式碼仍跑在 Node.js 上，你的測試仍用現有的執行器，但你的 node_modules 被填充的速度快上 10 倍。如果這運作良好，你可以逐步採用更多 Bun 工具組。

**Bun 在 2026 年是否生產就緒？**作為套件管理器，是的，但需測試。作為 Node.js 的完整執行環境替代品，請針對你的特定相依性審慎評估。

遷移指南

npm 到 pnpm（最熱門的遷移）

這是最輕鬆的遷移路徑。pnpm 原生讀取 npm 的 lockfile：

1. 安裝 pnpm：corepack enable，然後在 package.json 加上 "packageManager": "[email protected]"
2. 匯入你的 lockfile：pnpm import（將 package-lock.json 轉換為 pnpm-lock.yaml）
3. 清理：刪除 node_modules 與 package-lock.json
4. 安裝：pnpm install
5. 全面測試：執行你的建置、測試與開發伺服器
6. 更新 CI 設定：在 GitHub Actions 切換到 pnpm/action-setup

npm 到 Bun（最快的路徑）

更簡單，Bun 直接讀取 package-lock.json：

1. 安裝 Bun：curl -fsSL https://bun.sh/install | bash
2. 執行：bun install（產生 bun.lock）
3. 測試：某些 postinstall 腳本可能需要在 package.json 設定 trustedDependencies
4. 更新 CI：加入 Bun 安裝步驟

遷移難度摘要

**專家提示：**不要在衝刺期間遷移。預留時間，測試你整個建置管線，並準備好回滾計畫。對多數團隊而言，npm 到 pnpm 的遷移確實毫無痛感。

何時用什麼：決策框架

這是每位讀者都為之而來的章節。依情境給出具體建議：

團隊規模指引

Techsy 如何挑選套件管理器

在 Techsy，我們用全部四款套件管理器交付過生產環境應用程式。以下是我們辛苦學到的經驗：

• 我們的預設是 pnpm，用於多數客戶專案。嚴格的相依性解析能在幻影相依性問題上線生產前就捕捉到它們。當我們的團隊同時在做 10 多個專案時，磁碟節省就很重要。而 Corepack 讓新開發者的上手毫無痛感——他們 clone repo、執行 pnpm install，一切就正常運作。

• 我們使用 Bun 於內部工具、CLI 腳本，以及速度至上的原型。我們也在某些客戶專案用 bun install 搭配 Node.js 執行環境——它給我們 Bun 的安裝速度，卻不必投入完整的 Bun 執行環境。

• 我們使用 npm 於快速原型，以及團隊本來就用 npm、遷移成本不划算的客戶專案。npm 沒問題。不是每樣東西都需要最佳化。

• 我們推薦 Yarn Berry 給需要 zero-installs 或既有 PnP 基礎設施的特定客戶環境。它是為特定需求打造的專用工具。

我們針對新專案的標準流程：評估專案的 monorepo 需求、檢查 CI 管線限制、考量團隊的熟悉度，然後預設用 pnpm，除非有特定理由不這麼做。

正在設定新專案，想從第一天就把工具弄對？我們的團隊用全部四款套件管理器交付過生產環境應用程式。預約免費架構諮詢。

最終裁決：2026 年的 npm vs Yarn vs pnpm vs Bun

如果你正在 2026 年挑選套件管理器，**pnpm 對多數團隊而言是最安全的選擇。**它快速、磁碟效率高、對相依性嚴格，並擁有最佳的 monorepo 工具。Bun 是令人興奮的未來——當速度是你的首要考量，或你想要一體化工具組時就用它。npm 沒問題，適用於你不想費心工具的簡單專案。Yarn Berry 是為想要 PnP 獨特優勢的團隊準備的專用選擇。

最好的套件管理器，是你整個團隊都達成共識的那一個。評估你專案的需求、選一個、用 Corepack 釘選它，然後開始打造。

來源

• npm Documentation，官方 npm CLI 參考與指南
• pnpm Documentation，官方 pnpm 文件，包含基準測試與遷移指南
• Yarn Documentation，官方 Yarn Berry (v4) 文件與 Plug'n'Play 參考
• Bun Documentation，官方 Bun 文件，涵蓋執行環境、套件管理器與工具
• pnpm.io Benchmarks，pnpm 官方安裝速度基準測試（2026 年 2 月 8 日）
• edbzn/package-manager-benchmarks，比較 npm、Yarn、pnpm 與 Bun 的開源基準測試套件

常見問題

哪一個是最快的 JavaScript 套件管理器？

Bun，而且領先幅度相當大。在 M3 MacBook Pro 的基準測試中，Bun 在 0.8 秒內安裝完一個 50 個相依性的專案，相較於 npm 的 14.3 秒。pnpm 是 Node.js 原生選項中最快的，同一專案為 4.2 秒。

pnpm 比 npm 好嗎？

對多數專案而言，是的。pnpm 更快、使用更少磁碟空間（跨專案節省 50-70%）、防止幻影相依性，並有更好的 monorepo 支援。代價是：略陡的初始學習曲線，以及少數假設扁平 node_modules 的舊套件邊緣案例。

Bun 在 2026 年是否生產就緒？

作為套件管理器，是的。bun install 適用於 Node.js 專案，且有 98% 的 npm 相容性。你可以把 Bun 當作套件管理器使用，而不切換執行環境。作為 Node.js 的完整執行環境替代品，請在投入前仔細測試你的特定相依性。

我該從 npm 切換到 pnpm 嗎？

如果你在做多個專案或 monorepo，該。遷移幾乎是隨插即用：執行 pnpm import 轉換你的 lockfile、刪除 node_modules，再執行 pnpm install。如果你只有一個小專案，而 npm 沒造成問題，就沒有急迫性。

Bun 會取代 npm 嗎？

Bun 可以取代 npm 作為套件管理器，但它同時也是更多東西：一個 JavaScript 執行環境、打包器與測試執行器。你可以只用 bun install，而不把 Node.js 換成你的執行環境。把它想成：用 Bun 做它最擅長的事（快速安裝），其餘一切則維持你現有的技術棧。

Yarn 在 2026 年還有意義嗎？

Yarn Berry (v4) 有意義，對想要 Plug'n'Play 與 zero-installs 的團隊而言。它的 JS constraints 引擎確實獨一無二。然而，Yarn Classic (v1) 已進入維護模式，應該遷移離開。如果你還在用 Yarn Classic，請轉向 pnpm 或 Yarn Berry。

什麼是幻影相依性？

即使你從未把它們加進 package.json，卻能在程式碼中 import 的套件。它們之所以出現，是因為 npm 和 Yarn Classic 會將傳遞相依性提升到 node_modules 頂層。你的程式碼能運作，直到某次相依性更新移除了那個傳遞套件，然後它在生產環境崩潰。pnpm 以嚴格的相依性解析防止這一點。

哪款套件管理器最適合 monorepo？

pnpm。它擁有最成熟的 workspace 過濾（--filter）、套件間嚴格的相依性隔離，以及 workspace 協定支援（workspace:*）。Yarn Berry 以其 constraints 引擎穩居第二。Bun 正以 v1.3 的相依性 catalog 追趕。

什麼是 Corepack？

一個 Node.js 內建工具（自 v16.9 起），用於管理套件管理器版本。在你的 package.json 加上 "packageManager": "[email protected]" 並執行 corepack enable。Corepack 確保每個開發者與 CI runner 都使用那個確切版本——無需手動安裝、沒有版本漂移。

我能在既有的 npm 專案使用 Bun 嗎？

可以。在任何有 package.json 的專案執行 bun install。Bun 會讀取 package-lock.json 與 yarn.lock 檔案。你不需要變更專案結構，而你的程式碼仍跑在 Node.js 上。

我該如何從 npm 遷移到 pnpm？

執行 pnpm import 將 package-lock.json 轉換為 pnpm-lock.yaml、刪除 node_modules 與 package-lock.json、執行 pnpm install，然後測試你的建置管線。對多數專案而言，整個過程大約花 30 分鐘。

Next.js 用哪款套件管理器？

Next.js 與四款都能協作。create-next-app 預設用 npm，但支援 --use-pnpm、--use-yarn 與 --use-bun 旗標。Vercel 的 CI 平台原生支援 pnpm，而 Next.js 社群因其嚴格相依性解析與 monorepo 支援而重度偏好 pnpm。