淘宝 NPM 源竟然会篡改包的下载版本

[bianjp]

淘宝源擅自把 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)，似乎是比较纯净的，准备试用下。

[shakukansp]

一直是代理连官方源

[weixind]

真难伺候。

[dejavuwind]

没事儿别碰国内这些大厂

[dif]

打开代理，去掉各种第三方源。一样丝滑。
国内程序员必修课，佛跳墙。

[bianjp]

开发者本地翻墙没问题，但是公司的 CICD 服务器、NPM 私服都部署在内网服务器上，且不允许翻墙，所以只能找个国内的 NPM 代理。

[Mithril]

你的 CICD 直连外网拉包么。。。
正常情况下 CICD 应该只用内网缓存过的二进制，这样才能保证你产品的安全，出了问题也可追溯。
特别是 NPM 这种一大把前科的东西。

只从缓存取的话，应该不会有问题的。

[Melting]

确实 path-to-regexp@1.8.0 是一个 bug version ，但是也不应该有 npm 源来进行纠错

[mercury233]

合理一点的做法是默认不允许安装，加参数强制安装，默认替换是什么操作

[billlee]

他们是给自己开发的，只是顺便公开出来给大家用一下

[webbillion]

赞同 9 楼，镜像源这个东西你不用他们好像没任何损失

[Hyperion]

其实关键并不是 npminstall 的这个提交，可能、应该、也许出发点是好的
https://github.com/cnpm/npminstall/pull/256

但在全局引入这种污染行为，是在 cnpmcore 的这个提交
https://github.com/cnpm/cnpmcore/commit/a309edfa2e4a34d2a96fe36ffadea13e60f453ba

也就是在这个提交之后，bug-version 扩散到了整个镜像源

觉得没有问题的，多半应该也是不会看命令行 warning ，装不了删删 lock 对不对啊，那也就无所谓了嘛对不对啊

反正之前 bun 的 pr 里 cnpm 相关讨论看下来，维护者对这种操作还挺自豪的

所以，cnpm 是顺便给国内开发者用的这个定义应该是不会错的，这就不是个正经源

部署还是封装成 docker 整个扔上去算了

[andyskaura]

这种时候就需要赛博大善人出马了。 dockerhub 和 npm 都可以用 cf worker

[yuhuai]

我建议是设置下.npmrc ，下载你需要的包上传到内网的包管理服务器，例如 gitea 的包管理或者 Nexus,然后替换你本地的引入

[bianjp]

@Mithril CICD 使用内网 NPM 私服，但私服只缓存二进制文件，仍会实时（或只缓存一小段时间）从上游 NPM 源获取包的 metadata 信息。

[bianjp]

@yuhuai NPM 包数量太多了，手动上传不可行，只能搞代理 + 缓存。

[swim2sun]

可以理解 op 的状况，本地开发还好，CI 很多情况下是不能用代理的，就算能用代理 下载速度也是没法跟用国内镜像源相比

希望 op 测试出好用的镜像源后能跟大家分享一下

[xiaozhenga]

只能换新的镜像源了

[LaoChen]

大开眼界

[herozzm]

之前国内的 docker 仓库也会存在这些问题

[kongkx]

让公司在外网做一个 npm 私服穿墙，然后内网私服连外网私服， 🐶