从另一个文件夹访问 node_modules答案

【问题标题】：Access node_modules from another folder从另一个文件夹访问 node_modules
【发布时间】：2016-07-29 06:02:04
【问题描述】：

最近开始使用 Gulp，但我不知道是否真的有必要在当前项目的文件夹中直接拥有 node_modules 的副本？例如。我有这个结构：

我的网站
└─建造者
└──node_modules
└─工作
└─工作2

如何在不复制文件夹的情况下从文件夹“work”或“work2”访问文件夹“builder”中的 node_modules？它非常大，大约 100mb，在我看来，为每个新项目都拥有它的副本是没有意义的。

我在 package.json 文件中尝试了这一行 export NODE_PATH='D:\OpenServer\domains\mysite\build'，然后尝试了命令 gulp，但它回复了
[10:24:27] Local gulp not found in d:\OpenServer\domains\mysite\work [10:24:27] Try running: npm install gulp

【问题讨论】：

找到了一个部分解决方案，将文件夹 'work'、'work2'... 放在文件夹 'builder' 中，因为 node_modules 可以在父文件夹中识别。
为什么要把node_modules放到builder里面呢，为什么不直接放到mysite里面呢？
虽然不推荐，但你始终可以使用相对路径，即require('./builder/node_modules/....')
它从当前脚本向上遍历路径，直到找到node_modules/ - 如果到达根目录时该目录不存在，则失败。 require() 也接受一个以./ 或只是/ 开头的路径。在这种情况下，它会将其视为文件路径。请记住，NPM 和 Node.js 是两个独立的系统。 node_modules/ 约定是 Node.js 的东西，package.json 约定是 NPM 的东西。
这也是 Github 上的 NPM 存储库中正在进行的讨论。有一个模块缓存存在于您的主目录中，尽管目前所有内容都被复制了。在我看来，模块应该从该目录进行符号链接，这是一个恒定的时间操作。但是 NPM 所有者似乎并不同意 :)

标签： node.js npm gulp

【解决方案1】：

也许你应该把你的 package.json 放到你的根目录（mysite/package.json），
然后尝试在根目录上安装 node_modules。
此外，您将 gulpfile 写入同一目录。

例如。

mysite  
|- package.json  
|- node_modules  
|- gulpfile.js  
└─builder  
└─work  
└─work2

但是，我建议您为每个项目编写一个 gulpfile。

【讨论】：

谢谢。现在对我来说越来越清楚了。我认为针对我的情况的最佳解决方案是将node_modules 放入mysite，然后使用自己的package.json 和gulpfile.js 创建mysite 的子目录

【解决方案2】：

简答

不要这样做。让 NPM 以它设计的方式工作。但是，为了节省空间，您可以删除当前处于休眠状态的项目上的 node_modules 文件夹，并在切换回它们时使用npm install 的单次快照重新创建它。

理由

即使你共享你的 node_modules，你也可能有冗余。接下来你会怎么处理它们？

NPM 的本质是为每个项目复制模块。如果您深入研究 node_modules 文件夹树，您可能会注意到它甚至可以在一个给定的依赖关系树下包含同一库的多个复制。假设您明确地请求了两个模块，而这两个模块本身都提取了一个依赖关系来处理很多事情，因此称为lib_DADDYMUMMY：

node_modules
    + a_module_you_use v0.5
        + lib_DADDYMUMMY v0.1 (pulled as a dependency of this module)
    + another_module_that_you_requested v0.3
        + lib_DADDYMUMMY v0.1 (again ! pulled as a dependency of this other module)

当您的两个模块开始需要不同版本的lib_DADDYMUMMY 时，这会派上用场。当您维护长期项目时，这会派上用场！地狱知道，在 JavaScript 世界中，随着 API 的快速变化，您可以认为大多数体面的项目都是长期存在的。 :)

可以想象，每个人都可以共享所有依赖项，生活在一个扁平的结构中，几个版本的库彼此相邻，每个人都可以在那里找到他需要的东西。该存储库可以称为.m2。但不幸的是，这不是 NPM 的工作方式。

NPM 认为存储空间很便宜。这就是它帮助您管理依赖关系中的版本、依赖关系的依赖关系和依赖关系的依赖关系的代价。我认为，当work 和work2 在他们的生活继续进行不同的维护路径时，这是一个负担得起的处理肮脏工作的价格。我不会尝试通过强制使用类似 Maven 的文件夹模型来妨碍它。

【讨论】：

谢谢 :) 是的，我明白了。可能各种复杂的项目都需要自己的节点模块。但是我主要需要在 Gulp 中为几个前端项目运行类似的任务，比如编译 sass、优化图像、将多个文件合并为一个等......将一个 node_modules 共享给所有这些类似的项目不是更好吗？
一开始就是这样。如果您的项目都具有相同的结构，并且始终保持不变，那么它将是那样的。但是，如果 work 和 work2 将文件合并到外观非常不同的源代码树中，并且一年后 work2 得到维护，现在使用新的 SaSS 功能，而 work 依赖于您编写时可以使用的指令但如果 SaSS 人员认为已经过时，您将遇到麻烦，并面临大量不必要的维护开销。 :)
谢谢，但这个解决方案对我来说不是最好的...... :) 因为npm install 需要很多时间。如果我只需要在一个文件中进行一些更改，那就不值得了。我在这里看到很多警告不要为多个项目共享一个 node_modules ......但我会尝试 :D 好吧，如果我将来会遇到麻烦，那将是我不应该如此固执的经验 :D 但现在它在我看来，这是快速访问类似项目和创建新项目的最佳解决方案。
固执是一种品质，直到一个人变得固执固执。 ;) 保重！
每次将 100MB 复制到另一个文件夹或花费 10 分钟从头开始安装都是浪费空间/时间。

【解决方案3】：

您不应该这样做的一个问题是版本控制。如果你的模块需要同一个包的不同版本，你就会遇到问题。一个包会赢，它可能会破坏另一个包。

此外，您会遇到必须以某种方式合并依赖项列表的问题 - 这意味着您必须从 work/package.json、work2/package.json 等获取依赖项，然后一次安装所有这些.

合并 node_modules/ 也不能解决您的问题 - 相信我，不要尝试。

【讨论】：

好的，但是至少当两个项目需要所有相同的模块时，为什么不给他们两个相同的模块文件夹呢？
@Julia 因为这很难管理。两个模块中的第二个需要另一个依赖，package.json 不同。

【解决方案4】：

将node_modules 文件夹粘贴到您的mySite 目录中。

所有npm packages（例如gulp）都可以在您的work 或work2 目录中使用。

但是，现在（您的文件夹结构）工作文件夹在其父目录中找不到 node_modules。

【讨论】：