从另一个文件夹访问node_modules [英] Access node_modules from another folder

问题描述

最近开始使用Gulp，我不知道是否真的需要在当前项目的文件夹中直接复制一个node_modules吗? 例如.我有这个结构:

Recently started working with Gulp and I can't figure out is it really necessary to have a copy of node_modules directly in folder with current project? E.g. I have this structure:

mysite
└─建筑商
     └──node_modules
work─工作
work─work2

mysite
└─builder
      └──node_modules
└─work
└─work2

如何从文件夹"work"或"work2"访问文件夹"builder"中的node_modules而不进行复制?它很大，大约100mb，在我看来，为每个新项目都复制一个副本是没有意义的.

How can I access node_modules in folder 'builder' from folder 'work' or 'work2' without copying it? It is quite large, about 100mb, and seems to me it has no sense to have a copy of it for every new project.

我在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

I tried this line export NODE_PATH='D:\OpenServer\domains\mysite\build' in file package.json and then tried command gulp but it replied
[10:24:27] Local gulp not found in d:\OpenServer\domains\mysite\work [10:24:27] Try running: npm install gulp

推荐答案

简短答案

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

Don't do it. Let NPM work the way it's designed to. However, to save space, you can delete the node_modules folder on projects that are currently dormant, and recreate it with a single shot of npm install when you switch back to them.

正当化

即使您共享自己的node_modules，也可能会有冗余.接下来您将如何处理他们?

Even if you share your node_modules, you'll probably have redundancies in it anyway. What will you do about them next ?

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

It is the essence of NPM to replicate modules per project. If you dig into the node_modules folder tree, you may notice that it can even contain several replications of a same library under one given dependencies tree. Say you requested two modules explicitely, and both these modules themselves pulled a dependency that takes care of a lot of things, and is therefore called 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的快速变化，您可以认为大多数像样的项目都是长期存在的. :)

This comes in handy when your two module start needing different versions of lib_DADDYMUMMY. This comes in handy when you maintain long-lived projects ! And hell knows that in the JavaScript world, with fast changing APIs, you can consider most any decent project as long-lived. :)

一个人可以想象，所有依赖关系都由一个扁平的结构共享，并且每个人都在一个地方找到自己需要的东西，每个人都住在一个扁平的结构中.该存储库可以称为.m2.不幸的是，这并不是NPM的工作方式.

One could imagine having all dependencies being shared by everyone, living in a flat structure, with several versions of a library living next to each other and every one finding what he needs there. That repository could be called, say, .m2. But that's just not the way NPM works unfortunately.

NPM认为存储空间很便宜.这是帮助您管理依赖关系中的版本，依赖关系的依赖关系以及依赖关系的依赖关系的价格.我认为，当work和work2随着生活的发展而采取多样化的维护方式时，照顾肮脏的工作是可以承受的价格.我不会试图通过强迫一个类似Maven的文件夹模型来阻挠它.

NPM considers that storage space is cheap. That's its price for helping you manage versions in dependencies, dependencies of dependencies, and dependencies of dependencies of dependencies. I consider that it's an affordable price for taking care of the dirty jobs the day when work and work2, as their lives go on, take diverging maintenance paths. I wouldn't try getting in its way by forcing a half-Maven-like folder model.

这篇关于从另一个文件夹访问node_modules的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！