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

这个问题还有点奇怪，实际上 package-lock.json 中存储了完整的下载地址，应该不受 NPM 源修改下载地址影响，但确实有些构建流程报了 checksum 校验失败。除非是 1.8.0 的下载地址返回了 1.9.0 的文件内容，现在不能复现，下次遇到我再分析下。

找到问题了，有些工程中只有 yarn.lock, 没有 package-lock.json, 但在 CICD 中却使用 npm 安装依赖（可能是因为以前 CICD 容器未预装 yarn ），而 npm 只会使用 yarn.lock 中的 checksum, 但不会使用里面的下载地址，所以下载到了新版本，跟旧的 checksum 比对自然不一致。

这事开发者的责任更大。

[shakukansp]

一直是代理连官方源

[weixind]

真难伺候。

[dejavuwind]

没事儿别碰国内这些大厂

[dif]

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

[bianjp]

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

[Mithril]

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

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

[Melting]

确实 [email protected] 是一个 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 私服穿墙，然后内网私服连外网私服， 🐶

[lyxxxh2]

很久没用过国内镜像了。
pip npm composer go 通通走代理。
速度比国内镜像还快,也各种奇葩的网络小问题。

ps: 公司电脑内网服务器:
export http_proxy=http://192.168.50.30:7890
export https_proxy=http://192.168.50.30:7890

外网服务器没辙,装代理客户端麻烦。

[lyxxxh2]

@lyxxxh2
速度比国内镜像还快,也没各种奇葩的网络小问题。

[IvanLi127]

我一直以为淘宝源有 bug ，一直很抵触用淘宝源，原来是我错怪他了🤭原来不是镜像源呀

[unco020511]

你们公司内部没有代理镜像吗?

[shiny]

之前本来 bun 要默认使用淘宝镜像，也是因为会替换版本所以没有上。
https://github.com/oven-sh/bun/pull/12936#issuecomment-2265147603

> npmmirror has a BugVersionService which will replace the manifest of version A (which has bugs) with version B (fixed version). This mechanism will cause the integrity inconsistency between npmmirror and other registries.

[wheat0r]

@bianjp #5 自己搭代理呗

[LLaMA2]

CICD 不能用外网也没什么大问题,

开发时使用在线源,推到线上版本全部都是用 tgz 的本地包,

依赖库包 tgz 文件全部推送到代码仓库.不使用在线安装就不用担心连不上 npm 源了

[kilvn]

@lyxxxh2 #21 那可太简单了，外网服务器用 docker 起个 client 容器，直接走容器的端口不就好了，环境隔离没风险。

[BaiLinfeng]

居然没看懂，啥情况？

[Vegetable]

@shiny 真就是负负得正了，bun 这个改动也是骂声一片，现在好了。

[Rorysky]

@lyxxxh2 我全部用清华源 os/语言/库...

[vishun]

我去，这你么一个镜像随便改源的东西，还从来没有告知过，简直有病啊。
更好的方法是提供一个正常镜像地址，一个 bug 修复镜像地址，如果只提供 bug 修复镜像地址，也应该在官网明确告知啊。

[lyxxxh2]

@Rorysky
composer go pip 那些还好。
npm 就很不省心,镜像了,但又没完全镜像。
之前下载公司项目,cnpm 和换源总是网络超时。
后面直接 npm set proxy,就没操过这种心了。