npm node_modules 为什么会是现在这样

warning 地狱

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

有一部分原因应该和 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 的事还不一定呢，所以干脆就别改了，现凑活凑活用过这几年算了吧（逃

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

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

--

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

依赖要学会精简呢...
nodejs 一般项目也就 60m 左右 vue 项目 100m 左右
如果大的太离谱.是不是项目第三方用太多造成的..
有些东西能自己开发就少用第三方库.万年不升级优化 package.json 那也是项目大坑

@Rrrrrr .npmignore 就可以不发布. 作者的问题而已.

@joesonw 那也是不够规范。比如某个包超过一定的依赖，它就得锁住，不然开发者一删除，就全挂了

一个函数都要引用一下依赖，各种 README，能不大吗。

node_modules 占用空间其实都还能忍受，关键是它小文件太多啊，这点太要命了，拷贝删除都非常的慢，慢的令人发指

@lbunderway go 挺好用的啊 不是有 go.mod 吗 而且在依赖库文件体积上 go.mod 要比 manven composer 这些小多了

@yejinmo 你看他说 go 的包管理不咋样，就知道了 ，完全不懂别的语言，node js 的包管理比其他的差多了

1 楼 go 黑给我看笑了

现在的还行了，前几年的时候 node_modules 还是循环嵌套的，那才叫恶心。。

@fernandoxu 现在也是