node.js - 从另一个文件夹访问 node_modules

Question

最近开始使用 Gulp，我不知道是否真的有必要在当前项目的文件夹中直接复制 node_modules？例如。我有这样的结构:

我的网站
└─ build 者
└──node_modules
└─工作
└─work2

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

我在文件 package.json 中尝试了这一行 export NODE_PATH='D:\OpenServer\domains\mysite\build' 然后尝试了命令 gulp 但它回复了< br/>[10:24:27] 在 d:\OpenServer\domains\mysite\work 中找不到本地 gulp
[10:24:27] 尝试运行:npm install gulp

Answer 1

简答

不要这样做。让 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 时，这会派上用场。当您维护长期项目时，这会派上用场! hell 知道，在 JavaScript 世界中，随着 API 的快速变化，你可以认为大多数体面的项目都是长期存在的。 :)

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

NPM 认为存储空间很便宜。这就是帮助您管理依赖项中的版本、依赖项的依赖项以及依赖项的依赖项的依赖项的代价。我认为，当 work 和 work2 随着他们的生活继续采取不同的维护路径时，处理脏工作是一个可以承受的价格。我不会试图通过强制使用类似 Maven 的文件夹模型来妨碍它。