从另一个文件夹访问 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:

我的网站
└─建造者
      └──node_modules
└─工作
└─工作2

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:OpenServerdomainsmysiteuild' 然后尝试了命令 gulp 但它回复了
[10:24:27] 在 d:OpenServerdomainsmysitework 中找不到本地 gulp[10:24:27] 尝试运行:npm install gulp

I tried this line export NODE_PATH='D:OpenServerdomainsmysiteuild' in file package.json and then tried command gulp but it replied
[10:24:27] Local gulp not found in d:OpenServerdomainsmysitework [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_DADDYMMY :

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屋！