来自其他文件夹的模块
最近开始与Gulp合作，我无法弄清楚是否真的有必要在当前项目中直接在文件夹中复制node_modules？ 例如我有这样的结构：
我的网站
└─builder
└──node_modules
└─work
└─work2
如何在不复制文件夹的情况下从文件夹'work'或'work2'访问文件夹'builder'中的node_modules？ 这是相当大的，大约100mb，在我看来，对于每个新项目都有一份副本是没有意义的。
我试过这一行在文件package.json中export NODE_PATH='D:OpenServerdomainsmysitebuild' ，然后尝试命令gulp但它回复了
[10:24:27] Local gulp not found in d:OpenServerdomainsmysitework [10:24:27] Try running: npm install gulp
简短的回答
不要这样做。 让NPM按照其设计的方式工作。 但是，为了节省空间，您可以删除当前处于休眠状态的项目上的node_modules文件夹，并在切换回npm install时使用一次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和work work2当他们的生活继续时，采取不同的维修路径时，照顾脏兮兮的工作是一种合理的价格。 我不会试图通过强制一个类似Maven的文件夹模型来阻止它。
也许你应该把你的package.json放到你的根目录（mysite / package.json）中，
然后尝试在根上安装node_modules。
另外，你在同一个目录下写gulpfile。
例如。
mysite
|- package.json
|- node_modules
|- gulpfile.js
└─builder
└─work
└─work2
但是，我建议您为每个项目编写一个单独的gulp文件。
将node_modules文件夹粘贴到mySite目录中。
所有npm packages ，如gulp会在你的工作， work或work2目录。
但是，现在（您的文件夹结构）工作文件夹无法在其父目录中找到node_modules 。