最近开始使用Gulp，我不知道是否真的有必要在当前项目的文件夹中直接拥有一个node_modules的副本？例如。我有这样的结构:
MySite
Builder
nbsp； nbsp；节点_模块
工时
工时2
如何从文件夹'work'或'work2'访问文件夹'builder'中的node_modules而不复制它？它相当大，大约100MB，在我看来，为每个新项目都有一个它的副本是没有意义的。
我在文件package.json中尝试了这行export node_path='d:\openserver\domains\mysite\build'，然后尝试了命令gulp，但它回复了[10:24:27]在d:\openserver\domains\mysite\work[10:24:27]中找不到本地gulp Try running:npm install gulp
简短回答
别这么做。让NPM按照设计的方式工作。但是，为了节省空间，您可以删除当前处于休眠状态的项目上的node_modules文件夹，并在切换回项目时使用npm install来重新创建该文件夹。
正当理由
即使您共享了node_modules，也可能会有冗余。接下来你会怎么处理他们？
在每个项目中复制模块是NPM的本质。如果您深入NODE_MODULS文件夹树，您可能会注意到，它甚至可以在一个给定的依赖关系树下包含同一个库的多个复制。假设您明确地请求了两个模块，这两个模块本身都提取了一个依赖项，该依赖项负责处理很多事情，因此称为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式的文件夹模型来阻碍它。
也许您应该将package.json放入根目录（mysite/package.json），
然后尝试在根目录上安装node_modules.
此外，您在同一目录上编写gulpfile。
例如。
mysite
|- package.json
|- node_modules
|- gulpfile.js
└─builder
└─work
└─work2
但是，我建议您为每个项目编写一个gulpfile。
为什么你不应该这样做的一个问题是因为版本控制。如果您的模块需要同一个包的不同版本，那么您就会遇到问题。一个包会赢，它可能会打破另一个包。
此外，您还会遇到必须以某种方式合并依赖项列表的问题--也就是说，您必须从work/package.json，work2/package.json等获取依赖项，然后一次安装所有依赖项。
合并node_modules/也不能解决您的问题--相信我，不要尝试。
