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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

推荐关注

› Meteor

› JSLint - a JavaScript code quality tool

› jsFiddle

› D3.js

› WebStorm

推荐书目

› JavaScript 权威指南第 5 版

› Closure: The Definitive Guide

这是一个创建于 370 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

第 1 条附言 · 2024-09-12 15:17:25 +08:00

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

第 2 条附言 · 2024-09-12 16:36:28 +08:00

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

这事开发者的责任更大。

淘宝源

篡改

版本

33 条回复 • 2024-09-13 13:16:07 +08:00

shakukansp

2024-09-12 10:07:51 +08:00

一直是代理连官方源

weixind

2024-09-12 10:09:24 +08:00

真难伺候。

dejavuwind

2024-09-12 10:15:38 +08:00

没事儿别碰国内这些大厂

dif

2024-09-12 10:20:19 +08:00

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

bianjp

PRO

2024-09-12 10:26:59 +08:00

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

Mithril

2024-09-12 10:33:09 +08:00

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

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

Melting

2024-09-12 10:37:10 +08:00

确实 [email protected] 是一个 bug version ，但是也不应该有 npm 源来进行纠错

mercury233

2024-09-12 10:41:34 +08:00

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

billlee

2024-09-12 10:44:31 +08:00

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

webbillion

2024-09-12 10:48:42 +08:00

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

Hyperion

2024-09-12 11:00:50 +08:00

其实关键并不是 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

2024-09-12 11:02:09 +08:00

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

yuhuai

2024-09-12 11:14:35 +08:00

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

bianjp

PRO

2024-09-12 11:25:48 +08:00

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

bianjp

PRO

2024-09-12 11:38:52 +08:00

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

swim2sun

2024-09-12 11:44:35 +08:00

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

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

xiaozhenga

2024-09-12 11:45:40 +08:00

只能换新的镜像源了

LaoChen

2024-09-12 12:56:19 +08:00

大开眼界

herozzm

2024-09-12 12:57:35 +08:00

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

kongkx

2024-09-12 13:09:26 +08:00 via iPhone

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

lyxxxh2

2024-09-12 13:09:51 +08:00

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

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

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

lyxxxh2

2024-09-12 13:10:15 +08:00

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

IvanLi127

2024-09-12 13:31:44 +08:00

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

unco020511

2024-09-12 14:16:52 +08:00

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

shiny

2024-09-12 15:20:52 +08:00

之前本来 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.