Nodejs 为什么 node 项目的依赖都要放在 node_modules 下，而不整个中心依赖库？
Nodejs 为什么 node 项目的依赖都要放在 node_modules 下，而不整个中心依赖库？
比如有 2 两个 node 项目，依赖同一个库，那么每个项目中的 node_modules 都有一份。这不是重复下载和浪费磁盘空间么？
java 就不这样，java 一般都是放在 repository 下面（我指的是使用 maven).
当然，我知道可以 node install -g 。
但是我了解到的实践中，都是每个项目一份 node_modules 。
难到把所有项目的依赖放在一起会有问题？
我记得 15 年的时候更恐怖，每一个库的依赖都放在自己库目录下的某个文件夹下（大概就是 node_modules ），
这样导致了路径很长的循环依赖。
我们在 Windows 上部署 CI 的时候，触发了路径超过 256 个字符的问题，当时我就震惊了，还能这样依赖的啊？
记得不是太清楚了，如有错误，欢迎指正。
之前也有人用这个做理由，说依赖同一个库但是版本不同。但是我后来想想发觉不对啊，你是可以依赖同一个库版本不同啊，你每个版本保存一份不就行了？好，问题来了，npm 有个天坑在于同一个包在本地无法多版本共存。于是它才不得不搞这种每个项目里都要塞一个依赖的做法
#2
#4
#9
java 就可以同一个库多版本并存啊，每个版本一个文件 夹不就行了
如 #17 所说，yarn 的 PnP 正解。
直接原因应该是实现简单(因为 npm 是完全独立于 Node 的，如果需要像 lz 附言里的图那样，要不改 Node (很不好改)，要不自己运行时注入一个 resolver)
其实有一个很方便的地方，一个项目用完了可以放心的直接 rm -rf 掉，不用担心残留在本地的依赖项。(npm i -g 的包通常都是 cli，在项目里 require() 不到。)
因为最早 web 端的依赖就是放在项目目录下。
比如你的页面引用了 jQuery，要么把它放在 CDN 上，要么放在项目的 web 目录下，如果放在系统级的中心仓库，那么要怎么通过 script 标签引用它呢？
后来有了 web 端的包管理工具，例如 bower，也是放在项目目录下的 bower_components，这样可以通过 /bower_components/xxx/xxx.js 这样子引用。
node_modules 只不过是继承了这种做法而已，在刚开始的时候，node 端的工具还不多，node 仓库里大部分还是前端库，有不少人拿 node_modules 当作 bower_components 使用，<script src="/node_modules/jquery/dist/jquery.js"> 这样子。
为了兼容性，这种设计就这样保留到了现在。
第三方库要考虑各种各样的情况，比如项目 A 依赖 “[email protected]“，项目 B 依赖 “[email protected]”，这时候就不能放在一起（实际情况比这负责的多），当然你可以说放在一块再按版本号子目录存放，但这一是增加了深度，二是它的作用随着“多个项目的公共依赖部分的减少而减少”，况且硬盘的成本是很低的，所以最终还是取舍的问题。
我觉得不是包放哪里的问题.
而是包发布的时候就应该是完整可运行的.它依赖什么,发布的时候就应该打包好.变成它代码的一部分.
用包的人不应该关心某个包依赖什么.下载依赖的时候,也不应该下载它的依赖
#35 这个也有历史原因，比如网页中用了三个 jQuery 的插件，肯定不可能每个插件自带一份 jQuery 。
现在也一样，一大堆 react-xxx 的库，也不能每个都自带 react 。
https://github.com/nodejs/node/issues/4584 早期也有人提出为什么不能像 maven 一样，或者自定义寻找依赖 resolve 的策略，但是回复是当时已经 lock 定稿了
- 把所有项目依赖放在一起会有问题？答：看需求，贴合需求就没问题，与需求矛盾就有问题。
2. 每个项目中的 node_modules 都有一份依赖是不是 Node 的机制？答：不是，这是 npm 的机制，Node 并没有强制要求每个项目的依赖放在项目自己的 node_modules 里。
3. Node 是否支持把所有项目依赖放在一起？答：支持，npm 只是一种包管理方案，Node 的包管理器有很多种，比如 pnpm 就是采用了把所有项目依赖放在一起的方案。
4. node_module 是否支持你把依赖放在多个项目的公共父目录下供所有子项目使用？答：支持，实际上如果当前目录下找不到依赖，Node 会尝试到上一级目录来查找依赖，一直到根目录： https://nodejs.org/api/modules.html#modules_loading_from_node_modules_folders
> If the module identifier passed to require() is not a core module, and does not begin with ‘/’, ‘…/’, or ‘./’, then Node.js starts at the parent directory of the current module, and adds /node_modules, and attempts to load the module from that location. Node.js will not append node_modules to a path already ending in node_modules.
> If it is not found there, then it moves to the parent directory, and so on, until the root of the file system is reached.
这个问题我也想过，当年因为 npm 都崇尚语义化版本号，这样方便升级，比如 package.json 里依赖了 lodash ^1.0.0 版本，那么执行 npm update 之后可以自动升级到 ^1.9.9 这样的版本上，只要是满足语义化版本的就可以升级。那么如果两个项目都写了 lodash ^1.0.0，我升级其中的一个，另一个也就 resolve 到 ^1.9.9 了，会导致不可预期的事情。但后面出了个 package-lock.json，这个文件里面就完整的记录了当前项目所用的版本甚至是包的下载路径，所以完全可以 resolve 到正确的版本上了，之所以不做应该就是大家习惯了，毕竟这样比较好向主子申请更好的电脑配置不是~
哈哈哈，以前水过一篇博客，对这块略有了解 https://linrz.me/2019/11/11/the-future-of-javascript-package-managment/
node 的最初开发者在 JSConf Eu 2018 上表示自己挺后悔在 node 中加个 node_module 文件夹的，而且引用还不是以.js 后缀结尾，直接模块名。种种开发 node 时让他觉得很羞耻的东西，让他决定在离开了 node 团队多年后，再去开发另外一个 V8 运行时——deno 。;)
详见油管。10 things I regret about node.js – Ryan Dahl
一句话就是，node 是为了解决多版本冲突引入的这家伙。
http://npm.github.io/how-npm-works-docs/npm3/how-npm3-works.html
为了解决 node 这个坑（还有超级多的其它坑），于是有了 deno
在Node.js项目中，依赖之所以要放在node_modules目录下，而不是整个中心依赖库，主要有以下几个原因：
-
模块化与封装：
- Node.js采用模块化设计，每个模块（或包）都可以独立开发、测试和部署。
node_modules目录作为项目的本地依赖库，确保了每个项目拥有自己独立的依赖环境，避免了不同项目间的依赖冲突。
-
版本控制：
- 每个依赖包在
node_modules下都有自己的版本信息，这有助于确保项目使用的依赖版本是稳定和兼容的。 - npm和Yarn等包管理器会生成
package-lock.json或yarn.lock文件，锁定依赖的具体版本，进一步保证版本的一致性。
- 每个依赖包在
-
便于开发与协作：
- 开发者只需在本地环境中运行
npm install或yarn命令，即可根据package.json文件自动安装项目所需的所有依赖。 - 这使得团队协作更加高效，每个开发者都可以在自己的本地环境中快速搭建起项目所需的依赖环境。
- 开发者只需在本地环境中运行
综上所述，将Node.js项目的依赖放在node_modules目录下，是实现模块化、版本控制和高效开发协作的重要机制。
