過去兩年，前端圈子經歷了一波又一波的供應鏈攻擊。npm 包被掛馬、作者賬號被盜、CI 工具被劫持，甚至連大廠項目也沒能幸免。

隨便舉幾個例子：

?Qix（資深維護者）賬號被釣魚，結果多個熱門包被投毒，受影響的 npm 包周下載量超過 20 億；

?DuckDB 因為釣魚郵件，依賴鏈直接被篡改；

?Nx 項目則栽在 GitHub Actions 的漏洞上，被黑客鉆了空子。

這些攻擊有個共性：惡意版本上線沒多久就會被刪掉。可問題是，如果你的項目或者自動化腳本第一時間拉了最新版本，那就妥妥成了“小白鼠”。

說白了：越是“追新”的項目，越容易中招。

pnpm 終于出手了

就在前幾天，pnpm 發布了 10.16，帶來一個非常實用的新功能：：minimumReleaseAge，即最小發布時間限制，它允許你為依賴版本設定一個“冷靜期”（單位：分鐘）。只有當某個 npm 包的版本發布超過這個時間，pnpm 才會安裝。

比如：

minimum-release-age=2880 # 48小時

意思就是：只安裝發布時間 ≥ 48 小時的版本。

剛上線的新版本？不好意思，先在外面冷靜兩天。

它解決了什么問題？

說白了，這個機制就是用來防“零小時攻擊”的。

黑客最愛玩的套路是：盜號或者釣魚，然后立刻發一個帶毒的新版本。雖然社區和官方通常會在幾個小時內下架或修復，但這段時間就像真空地帶——誰更新，誰中招。

有了 minimumReleaseAge，等于多了一層保險：

?新版本剛冒出來 → 先等等，不急著裝；

?社區發現問題 → 官方下架或補丁跟上；

?冷靜期過后再更新 → 基本就是更穩的版本了。

簡單粗暴，但很有效。

不止如此

pnpm 還貼心加了兩個實用補充：

?minimumReleaseAgeExclude** 配置**：可以給特定的包開后門。比如公司內部的私有包，緊急修復時就不用卡冷靜期。

?環境差異化：開發環境可以設得短（比如 1 小時），保證迭代快；生產環境可以設得長（比如 24 小時），上線更穩。

有啥副作用？

再好用的功能也不是沒代價：

?安裝速度可能慢一點，因為要取完整元數據；

?遇到零日修復，可能得手動調配置才能立刻更新；

?傳遞依賴多的時候，安裝結果有時會和預期不一樣。

不過，這些小問題和供應鏈攻擊相比，完全可以接受。

版本也要冷靜期

pnpm 并不是第一個提出這個思路的：

?Taze 在 19.6.0 就有 --maturity-period；

?npm-check-updates 也在搞 --cooldown；

?Dependabot 早就能延遲升級。

可以說，前端依賴管理圈子已經形成共識：升級別太著急，給版本留個緩沖期。

寫在最后

前端生態的繁榮離不開開源，但開源供應鏈的安全問題越來越尖銳。以前我們覺得“能升就升”，可現實一次次打臉：升級太快，風險最大。

pnpm 這次加的 minimumReleaseAge，就是一招直擊痛點的補刀：簡單、好用，還特別實在。

從此以后，終于不用擔心自己項目成小白鼠了。