淘宝源擅自把 path-to-regexp 1.8.0 版本的下载地址改成了 1.9.0 版本,导致使用了 package-lock.json, yarn.lock 的工程安装依赖失败( checksum 校验失败)。
淘宝源:
https://registry.npmmirror.com/path-to-regexp/1.8.0
官方源:
https://registry.npmjs.org/path-to-regexp/1.8.0
好像是这里引入的:
https://github.com/cnpm/bug-versions/pull/257/files
虽然是出于安全考虑,但这样篡改下载地址却影响了存量的 CICD 流程,给开发者造成不便,也破坏了与 NPM 官方源的兼容性(不能自由切换 NPM 源了)。一直以为淘宝源是官方源的纯净代理呢,没想到竟会做这样的事,看来要慎用了。同事说用腾讯云、华为云的 NPM 源也遇到过一些坑,看来想找个靠谱的国内 NPM 代理都不容易(前端圈这是怎么了?)。
中科大镜像站有个 NPM 源的反向代理(https://npmreg.proxy.ustclug.org),似乎是比较纯净的,准备试用下。
https://github.com/cnpm/npminstall/pull/256
但在全局引入这种污染行为,是在 cnpmcore 的这个提交
https://github.com/cnpm/cnpmcore/commit/a309edfa2e4a34d2a96fe36ffadea13e60f453ba
也就是在这个提交之后,bug-version 扩散到了整个镜像源,觉得没有问题的,多半应该也是不会看命令行 warning ,装不了删删 lock 对不对啊,那也就无所谓了嘛对不对啊。反正之前 bun 的 pr 里 cnpm 相关讨论看下来,维护者对这种操作还挺自豪的,所以,cnpm 是顺便给国内开发者用的这个定义应该是不会错的,这就不是个正经源,部署还是封装成 docker 整个扔上去算了。
正常情况下 CICD 应该只用内网缓存过的二进制,这样才能保证你产品的安全,出了问题也可追溯。特别是 NPM 这种一大把前科的东西。只从缓存取的话,应该不会有问题的。