过去两年 ，前端前端圈子经历了一波又一波的生态上供应链攻击 。npm 包被挂马 、屡遭作者账号被盗 、攻击CI 工具被劫持，终于甚至连大厂项目也没能幸免 。出手 随便举几个例子： •Qix（资深维护者）账号被钓鱼 ，前端结果多个热门包被投毒，生态上受影响的屡遭 npm 包周下载量超过 20 亿； •DuckDB 因为钓鱼邮件 ，依赖链直接被篡改； •Nx 项目则栽在 GitHub Actions 的攻击漏洞上 ，被黑客钻了空子。终于 这些攻击有个共性 ：恶意版本上线没多久就会被删掉 。出手可问题是前端 ，源码下载如果你的生态上项目或者自动化脚本第一时间拉了最新版本 ，那就妥妥成了“小白鼠” 。屡遭 说白了 ：越是“追新”的项目 ，越容易中招 。 pnpm 终于出手了就在前几天 ，pnpm 发布了 10.16 ，带来一个非常实用的新功能 ： ：minimumReleaseAge ，即最小发布时间限制 ，它允许你为依赖版本设定一个“冷静期”（单位 ：分钟） 。只有当某个 npm 包的版本发布超过这个时间 ，pnpm 才会安装 。香港云服务器 比如： 复制minimum-release-age=2880 # 48小时1.意思就是 ：只安装发布时间 ≥ 48 小时的版本 。 刚上线的新版本？不好意思 ，先在外面冷静两天。 它解决了什么问题 ？说白了 ，这个机制就是用来防“零小时攻击”的 。 黑客最爱玩的套路是 ：盗号或者钓鱼 ，然后立刻发一个带毒的新版本 。虽然社区和官方通常会在几个小时内下架或修复，免费模板但这段时间就像真空地带——谁更新 ，谁中招 。 有了 minimumReleaseAge ，等于多了一层保险 ： •新版本刚冒出来 → 先等等，不急着装； •社区发现问题 → 官方下架或补丁跟上； •冷静期过后再更新 → 基本就是更稳的版本了 。 简单粗暴，但很有效 。 不止如此pnpm 还贴心加了两个实用补充 ： •minimumReleaseAgeExclude** 配置** ：可以给特定的包开后门。比如公司内部的私有包 ，紧急修复时就不用卡冷静期 。 •环境差异化：开发环境可以设得短（比如 1 小时） ，保证迭代快；生产环境可以设得长（比如 24 小时） ，云计算上线更稳 。 有啥副作用？再好用的功能也不是没代价： •安装速度可能慢一点 ，因为要取完整元数据； •遇到零日修复 ，可能得手动调配置才能立刻更新； •传递依赖多的时候，安装结果有时会和预期不一样 。 不过 ，这些小问题和供应链攻击相比 ，完全可以接受 。 版本也要冷静期pnpm 并不是第一个提出这个思路的 ： •Taze 在 19.6.0 就有 --maturity-period； •npm-check-updates 也在搞 --cooldown； •Dependabot 早就能延迟升级 。 可以说 ，前端依赖管理圈子已经形成共识：升级别太着急 ，高防服务器给版本留个缓冲期。 写在最后前端生态的繁荣离不开开源 ，但开源供应链的安全问题越来越尖锐 。以前我们觉得“能升就升” ，可现实一次次打脸 ：升级太快 ，风险最大 。 pnpm 这次加的 minimumReleaseAge ，就是一招直击痛点的补刀：简单 、好用，还特别实在 。 从此以后 ，服务器租用终于不用担心自己项目成小白鼠了。 |
