从另一个文件夹访问node_modules

最近开始与Gulp合作,我无法弄清楚真的有必要直接在当前项目的文件夹中有一个node_modules副本? 比如我有这样的结构:

我的网站
└─builder
└──node_modules
└─work
└─work2

如何从文件夹“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

简短的回答

不要这样做。 让NPM按照其devise的方式工作。 但是,为了节省空间,您可以删除当前处于hibernate状态的项目上的node_modules文件夹,并在切换回npm install时使用一次npm install重新创build它。


理由

即使你共享你的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的快速变化,你可以把任何像样的项目视为长期的。 🙂

人们可以想象,每个人都拥有所有的依赖关系,生活在一个平坦的结构中,几个版本的图书馆彼此靠近,每个人都能find他所需要的东西。 该存储库可以被称为.m2 。 但是这不是NPM工作的方式。

NPM认为存储空间便宜。 这是帮助您pipe理依赖项的版本,依赖项的依赖项以及依赖项依赖项的依赖项的价格。 我认为,在work和工作的日子里,照顾脏兮兮的工作是一种负担得起的代价,因为他们的生活work2继续,维护路线不一样。 我不会试图通过强制一个类似Maven的文件夹模型来阻止它。

也许你应该把你的package.json放到你的根目录(mysite / package.json)中,
然后尝试在根上安装node_modules。
另外,你在同一个目录下写gulpfile。

例如。

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

但是,我build议您为每个项目编写一个单独的gulp文件。

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

所有npm packageswork2将在您的workwork2目录中work

但是,现在(您的文件夹结构)工作文件夹无法在其父目录中findnode_modules

为什么你不应该这样做的一个问题是由于版本控制。 如果你的模块需要同一个软件包的不同版本,你将遇到问题。 一个包就会赢,而且可能会打破另一个包。

此外,您遇到了以某种方式合并依赖项列表的问题 – 也就是说,您必须从work/package.jsonwork2/package.json等获取依赖关系,然后将其全部安装到一旦。

合并node_modules/不会解决您的问题,请相信我,不要尝试。