pnpm 12 RC 5 lockfile 變穩定了嗎？先驗證循環 peer 與 workspace CI

pnpm 12 RC 5 改了哪些可觀察行為#

這個 RC 影響的是 lockfile 產生條件與更新命令的副作用，主要可以分成四件事：

這些行為不是「所有 lockfile 都不會再變」。RC 重新解析既有循環 peer 時，可能重新替換 cycle variant 的 key；重點是同一份輸入在不同 workspace 排列或 cold install 下，應得到可解釋且一致的結果。

先把 RC 固定在可回退的測試範圍#

在隔離分支或測試工作副本安裝 RC，並把版本印進 CI log：

1
npm install --global [email protected]
2
pnpm --version
3
pnpm install --frozen-lockfile

如果團隊使用 Corepack、mise 或其他版本管理器，應沿用既有流程，只要求最後的 pnpm --version 明確顯示 12.0.0-rc.5。不要只在開發者電腦更新 global pnpm，卻讓 CI 透過未固定的 latest 自行取得另一個版本。

先用目前提交的 lockfile 跑一次 frozen install，再複製工作副本重新產生 lockfile。這兩個測試回答不同問題：前者確認 RC 能否消費現有輸出，後者確認 RC 解析後會不會改變 graph。

用兩次安裝驗證 lockfile 是否穩定#

測試 workspace 時，至少保留兩份輸入：一份是現有 pnpm-workspace.yaml 順序，另一份只調整 package glob 或 workspace package 的列出順序。兩次都使用相同的 Node、pnpm、registry 與 lockfile 設定，然後比較結果：

1
pnpm install --lockfile-only
2
cp pnpm-lock.yaml /tmp/pnpm-12-rc-5-first-lock.yaml
3

4
# 在另一個乾淨工作副本調整 workspace 列出順序後再執行
5
pnpm install --lockfile-only
6
diff -u /tmp/pnpm-12-rc-5-first-lock.yaml pnpm-lock.yaml

/tmp 檔案只適合本機暫存；CI 應改用 artifact 或直接在 job 中計算 hash。若 diff 只反映預期的 RC re-key，應回到 dependency graph 確認；若相同輸入仍因安裝順序、workspace 排列或 cold cache 產生不一致，就先不要把結果當成可升級訊號。

另外要測試一個包含互相依賴與 peer dependency 的最小 workspace。沒有 cycle 的單一套件專案只能證明一般安裝通過，無法覆蓋這次 RC 的主要改動。

pnpm update 要同時看 manifest 和 catalog#

pnpm 12 RC 5 的 release note 提醒，pnpm update 可能把新的版本範圍寫回 package.json 或 catalog:。因此更新測試要同時檢查：

1
git diff -- package.json pnpm-workspace.yaml pnpm-lock.yaml
2
rg -n 'catalog:|workspace:' package.json pnpm-workspace.yaml

如果團隊把版本集中在 catalog，不能只審查 pnpm-lock.yaml；如果依賴直接寫在 package manifest，也要確認更新範圍沒有從固定版本意外放寬。把這類 manifest diff 與 lockfile re-key 分開審查，reviewer 才能判斷哪些是解析實作變化、哪些是刻意升級依賴。

如果目前還在處理 GitHub 依賴的 CI transport 問題，可先對照 pnpm 11.21.0 修正 Git 依賴的驗證順序；那篇處理的是 Git URL 與 SSH 認證，這篇則專注在 pnpm 12 RC 的 lockfile 可重現性，兩者不要混成同一個升級結論。

要驗證「只安裝、不更新」的 CI 路徑，仍使用：

1
pnpm install --frozen-lockfile

這個命令不會替你修正新的版本範圍，也不會把未提交的 lockfile 變更藏起來；它的價值是讓 CI 在 manifest 與 lockfile 不一致時明確失敗。

哪些結果代表先不要升 production#

出現以下任一情況，先保留現有 pnpm 版本並回報可重現案例：

• 同一個 commit 在 cold cache 與 warm cache 產生不同 lockfile。
• 只調整 workspace package 的列出順序，就改變無關套件的 resolved graph。
• cycle peer 的 re-key 同時改變了實際版本，卻沒有對應的 manifest 或 resolution 設定變更。
• RC 讓 production workflow 的 --frozen-lockfile 失敗，但團隊還無法區分是 manifest、registry 或 lockfile 格式問題。
• pnpm update 修改了 catalog 或版本範圍，但 pull request 沒有把這個變更當成依賴升級審查。

反過來，如果兩次解析的差異都能對上官方 release note、frozen install 在乾淨 runner 通過，且 Node／pnpm／registry 輸入已固定，才有資格進下一輪 canary。RC 仍是候選版本，應保留一個可以快速回退的 package manager 設定。

常見問題#