npm node_modules 为什么会是现在这样

V2EX = way to explore

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

现在注册

已注册用户请登录

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

都在吐槽 npm 的设计，依赖地狱、小文件多、占用空间大、慢。

那是什么导致了 npm 必须设计成现在这样呢，其它语言的包管理工具为什么没有这些问题(比如 manven)？

node 包管理有没有新的方案在开发中？

第 1 条附言 · 2021-08-11 16:10:26 +08:00

看了这个帖子提的问

https://www.v2ex.com/t/794664#reply94

34 条回复 • 2021-09-07 09:20:39 +08:00

lbunderway

2021-08-11 15:40:11 +08:00

我觉得 npm 的报管理还行啊，
包的依赖是有改进地方，但没到地狱那么夸张吧，
小文件多是什么意思呢
项目 node_module 占用空间应该在 500M 以内吧，发布环境再指定环境安装再砍掉一半空间，就现在的硬件条件这个空间不是什么吧
慢是什么慢呢

其他语言不了解，至少比 go 好用，哈哈

zed1018

2021-08-11 15:42:48 +08:00

新版本的 npm 还行吧。或者换 yarn 。node_modules 里东西多，依赖复杂主要还是 js 生态没有一个比较强的 std lib 吧。啥都要导个包。依赖能少么。

chengxy

2021-08-11 15:44:06 +08:00

@lbunderway #1 慢应该是从 npm 服务器去找详细下载地址慢，如果有 lock 文件会快很多。

netwjx

2021-08-11 15:51:58 +08:00

是 java dotnet php... 等等以前古典语言的模块管理机制导致 npm 设计成现在这个样子的

也就是 npm 是一个纯粹为了工程上行得通, 没太考虑优美的方案

XTTX

2021-08-11 15:52:33 +08:00

反正我经常 npm install 报错，改用 yarn install 就没有问题。

learningman

2021-08-11 15:53:01 +08:00 via Android

其他语言也有这些问题的，有些是靠编译解决了一部分。
但是主要还是前端库太多了，依赖链条一长就变成这样了。

yejinmo

2021-08-11 16:21:37 +08:00

“项目 node_module 占用空间应该在 500M 以内吧”

这个吧好家伙 500M 算是可以接受的空间了么是真没见过别的语言的包管理机制？

sleepm

2021-08-11 16:33:07 +08:00

还可以试试 https://pnpm.io/

4771314

2021-08-11 16:39:44 +08:00

新版本的 npm 已经不错了，老版本的才是恶心，那时候真是地狱
也可以试下 yarn 和 pnpm，我感觉没有差太多
慢的问题可以看下网络和数据源的选择，国内可以使用淘宝或其他的数据源，会快一些

Rrrrrr

2021-08-11 18:02:10 +08:00

npm 本身还是没有规范。doc, src 为什么要上传。Github/gitlab 地址给出，让用户自己去看就好了。展平+单文件估计可以省很多空间。

ruxuan1306

2021-08-11 18:11:04 +08:00

@sleepm 看了下，感觉 npm install --global 又回来了

agagega

2021-08-11 18:12:15 +08:00 via iPhone

Ruby 默认是安装到语言目录而不是项目目录的，而且很久以前就有 lock 文件

otakustay

2021-08-11 19:30:44 +08:00

@ruxuan1306 倒也不是，global 只能 install 一个版本吧，pnpm 好歹让你感觉上和 local install 没有区别

MengiNo

2021-08-11 19:51:32 +08:00 via Android

go 感觉是比较完美的，特别是容器化后专门一个 volume 挂载 module 目录，所有项目通用。npm 黑洞真的心疼硬盘，不能理解为什么要一个项目一个包，PHP 是特殊的运行机制决定的，而 Node 工程化变成编译型语言后，为啥不和 go 那样设计成 "从仓库里找工具包" 的感觉。

Trim21

2021-08-11 20:07:03 +08:00 via Android

小文件多是因为 js 语言本身标准库不怎么样，挺多简单的功能不想自己写就得找个现成依赖。

JeffersonQin

2021-08-11 20:20:08 +08:00

@Trim21 捕捉 bangumi 大佬（之前有在论坛问过爬虫的问题🤣

luob

2021-08-11 20:25:47 +08:00

node_modules 无底洞这口锅分给谁都行，恰恰只有 npm 一点都分不上。反而是因为 npm 设计得非常优秀，各种循环依赖重复依赖版本问题都能得到解决，使得各种无底洞居然还能勉强跑起来。
你要觉得是 npm 过于优秀导致的大家胡乱搞依赖所以一定要分给它锅那我也无话可说。但是你说有没有新的方案在开发中就太扯了，难道要把功能全砍掉重新开发一个基于 git 地址的残废包管理器用强行增加用新包的难度来促使包的平均质量增加吗？

Trim21

2021-08-11 20:26:01 +08:00 via Android

@JeffersonQin 草，别这么叫，太尴尬了…

laozhoubuluo

2021-08-11 20:57:56 +08:00

依赖地狱、小文件多、占用空间大、慢不能说是 npm 的问题，是 JS 生态滥用三方包导致软件复杂度严重升高的结果，毕竟软件成品的复杂度肯定是大于需求的复杂度的。
甚至再说大一点，任何滥用三方包的应用程序或者说生态的成品都会遇到上述四个问题。每一层组件都滥用三方包之后，再用这些组件层层叠加组成的项目肯定是各种无底洞的，开发再聪明也无能为力。

rockdai

2021-08-11 21:53:22 +08:00

试试 https://github.com/cnpm/cnpm

MrKrabs

2021-08-11 21:54:15 +08:00

warning 地狱

wangkun025

2021-08-11 22:02:38 +08:00

看了下 ruby 的，我的 700 多 M，不过是共享的，当然也可以设置单独的 set 。

aristolochic

2021-08-11 22:09:59 +08:00

有一部分原因应该和 Node 依照文件系统逐级查找，且一个包有很多种入口可能性，需要按照 Fallback 顺序检测直到完成加载的模块 Resolution 机制有关。这种模型包括 CommonJS 设计之初是基于文件系统的访问速度很快可以忽略不记的假设成立之上的。连它本身都这么设计，npm 也没有道理不一切从简，然后就出现了比黑洞更深，令 Windows 瑟瑟发抖的恐怖存在。谁能想到之后会如此复杂，npm 也不得不做出调整。包括 yarn PnP 设计的一大理由就是没有理由惯着 Node 这么粗放动态的模块 Resolution 机制。

如果你说的是充当前端构建工具的 Node，那个占硬盘、小文件多、慢也占不到用户头上，如果乐意的话构建前安装，每次构建完了就删，和 CI 的思路就一样了；前端需要解决的问题复杂度已经很多人说过了，这个实在是没办法。另外谁叫所有人都在写 SPA，或许是图方便大量程序员间的协调？不少人说前端卷，好像在想尽办法提升后来人的入门台阶。这个确实有，比如各种 KPI 开源项目，不过这顶帽子怎么也安不到 npm 和 node_modules 上。

如果你说的是当后端使的 Node，除了有很多框架原生支持 TypeScript 之外，似乎很少有听说过后端需要编译的。后端领域因为环境可控，不太可能会引入前端的那些 Polyfill/Shim, Transpiling, Purge 库和相关的 Bundle 工具链等等，node_modules 不会很夸张。所以 Node 作为所谓 Server Side JS，其实并没有后端生态（ x

要说未来发展，听各位描述了一下 pnpm，似乎约等于 Node 版的 Bundler 啊。我还挺期待 yarn PnP 以后会是什么样子，毕竟 npm 抄过 yarn 的依赖扁平化，没道理不再抄一次。

不过私以为影响 Node （主要是前端）生态的最大问题是，再过几年可能所有人都去用 esbuild 这种压根不打包的工具（ Elixir Phoenix 1.6 就已经决定把 Node 和 webpack 踢了，自己管理 esbuild 。这样用一个单一的二进制，所有进程都由 Erlang BEAM Port 管理还恰恰更加符合 Elixir Mix 的特色），除了老项目之外还有没有 Node 的事还不一定呢，所以干脆就别改了，现凑活凑活用过这几年算了吧（逃

jsq2627

2021-08-12 02:49:30 +08:00

@aristolochic 就目前看来 pnpm 相当程度上夺走了 yarn 的风光。yarn 现在都出到 v3 了，PnP 生态还是没搞起来，各种主流框架工具（点名 typescript ）都没能全支持。更不用说一大堆人还停留在 yarn v1 。不过 yarn workspace 还是算比较给力的。

pnpm 算是用相当折中的方式来解决依赖地狱问题。尽管 node_modules 还是层层相套，但是 symlink 节省了很大空间，而且跨项目共享一个 store 。目前唯一问题是个别工具对 symlinked node_modules 兼容不够好（点名 jest ）。

--

这两年 esbuild / vite 爆火，webpack 也算是完成探索前端工程化的历史使命了