Nodejs npm node_modules 为什么会是现在这样
Nodejs npm node_modules 为什么会是现在这样
都在吐槽 npm 的设计，依赖地狱、小文件多、占用空间大、慢。
那是什么导致了 npm 必须设计成现在这样呢，其它语言的包管理工具为什么没有这些问题(比如 manven)？
node 包管理有没有新的方案在开发中？
新版本的 npm 还行吧。或者换 yarn 。node_modules 里东西多，依赖复杂主要还是 js 生态没有一个比较强的 std lib 吧。啥都要导个包。依赖能少么。
go 感觉是比较完美的，特别是容器化后专门一个 volume 挂载 module 目录，所有项目通用。npm 黑洞真的心疼硬盘，不能理解为什么要一个项目一个包，PHP 是特殊的运行机制决定的，而 Node 工程化变成编译型语言后，为啥不和 go 那样设计成 “从仓库里找工具包” 的感觉。
node_modules 无底洞这口锅分给谁都行，恰恰只有 npm 一点都分不上。反而是因为 npm 设计得非常优秀，各种循环依赖重复依赖版本问题都能得到解决，使得各种无底洞居然还能勉强跑起来。
你要觉得是 npm 过于优秀导致的大家胡乱搞依赖所以一定要分给它锅那我也无话可说。但是你说有没有新的方案在开发中就太扯了，难道要把功能全砍掉重新开发一个基于 git 地址的残废包管理器用强行增加用新包的难度来促使包的平均质量增加吗？
依赖地狱、小文件多、占用空间大、慢 不能说是 npm 的问题，是 JS 生态滥用三方包导致软件复杂度严重升高的结果，毕竟软件成品的复杂度肯定是大于需求的复杂度的。
甚至再说大一点，任何滥用三方包的应用程序或者说生态的成品都会遇到上述四个问题。每一层组件都滥用三方包之后，再用这些组件层层叠加组成的项目肯定是各种无底洞的，开发再聪明也无能为力。
有一部分原因应该和 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 的事还不一定呢，所以干脆就别改了，现凑活凑活用过这几年算了吧（逃
就目前看来 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 那也是项目大坑
关于“Nodejs、npm、node_modules为什么会是现在这样”，可以从以下几个方面进行解释：
Nodejs
Node.js是一个基于Chrome V8引擎的JavaScript运行时环境，用于构建快速、可扩展的网络应用程序。自2009年Ryan Dahl首次发布以来，Node.js凭借其高效的性能和丰富的生态系统，逐渐成为JavaScript开发者在服务器端的首选环境。
npm
npm（Node Package Manager）是Node.js的包管理器，由Isaac Z. Schlueter于2010年创立。它允许开发者轻松地安装、更新和管理项目中的JavaScript代码库的包或模块。npm的开放性和易用性使其迅速普及，成为JavaScript生态系统中最流行的包管理工具。
node_modules
node_modules文件夹是npm安装管理的依赖库所在目录。在Node.js项目中，当你使用npm安装包时，这些包会被下载并安装到node_modules文件夹中。由于node_modules的内容在npm install过程中可能会被重写或更新，因此直接修改其中的代码通常不生效，也不推荐这样做。
综上所述，Nodejs、npm以及node_modules的现状是JavaScript生态系统不断演进和完善的结果。它们共同构成了现代JavaScript开发的核心基础设施，为开发者提供了极大的便利。
