为什么在 npm 中为插件使用对等依赖项? [英] Why use peer dependencies in npm for plugins?

查看:31
本文介绍了为什么在 npm 中为插件使用对等依赖项?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

例如,为什么 Grunt 插件将其对 grunt 的依赖定义为对等依赖"?

Why does, for example, a Grunt plugin define its dependency on grunt as "peer dependencies"?

为什么插件不能在 grunt-plug/node_modules 中将 Grunt 作为它自己的依赖项?

Why can't the plugin just have Grunt as its own dependency in grunt-plug/node_modules?

对等依赖在此处描述:https://nodejs.org/en/blog/npm/peer-dependencies/

但我真的不明白.

示例

我目前正在使用 AppGyver Steroids,它使用 Grunt 任务将我的源文件构建到/dist/文件夹中,以便在本地设备上提供服务.我是 npm 和 grunt 的新手,所以我想完全理解发生了什么.

I'm working with AppGyver Steroids at the moment which uses Grunt tasks to build my source files into a /dist/ folder to be served on a local device. I'm quite new at npm and grunt so I want to fully comprehend what is going on.

到目前为止我得到了这个:

So far I get this:

[rootfolder]/package.json 告诉 npm 它依赖于 grunt-steroids npm 包进行开发:

[rootfolder]/package.json tells npm it depends on the grunt-steroids npm package for development:

  "devDependencies": {
    "grunt-steroids": "0.x"
  },

好的.在 [rootfolder] 中运行 npm install 检测依赖项并在 [rootfolder]/node_modules/grunt-steroids 中安装 grunt-steroids.

Okay. Running npm install in [rootfolder] detects the dependency and installs grunt-steroids in [rootfolder]/node_modules/grunt-steroids.

Npm 然后读取 [rootfolder]/node_modules/grunt-steroids/package.json 以便它可以安装 grunt-steroids 自己的依赖项.:

Npm then reads [rootfolder]/node_modules/grunt-steroids/package.json so it can install grunt-steroids own dependencies.:

"devDependencies": {
    "grunt-contrib-nodeunit": "0.3.0",
    "grunt": "0.4.4"
  },
"dependencies": {
    "wrench": "1.5.4",
    "chalk": "0.3.0",
    "xml2js": "0.4.1",
    "lodash": "2.4.1"
  },
"peerDependencies": {
    "grunt": "0.4.4",
    "grunt-contrib-copy": "0.5.0",
    "grunt-contrib-clean": "0.5.0",
    "grunt-contrib-concat": "0.4.0",
    "grunt-contrib-coffee": "0.10.1",
    "grunt-contrib-sass": "0.7.3",
    "grunt-extend-config": "0.9.2"
  },

依赖项"包安装到 [rootfolder]/node_modules/grunt-steroids/node_modules 中,这对我来说是合乎逻辑的.

The "dependencies" packages are installed into [rootfolder]/node_modules/grunt-steroids/node_modules which is logical for me.

未安装devDependencies",我确定这是由 npm 检测控制的,我只是尝试使用 grunt-steroids,而不是开发就可以了.

The "devDependencies" aren't installed, which I'm sure is controlled by npm detecting I'm just trying to use grunt-steroids, and not develop on it.

但是我们有peerDependencies".

这些安装在[rootfolder]/node_modules,我不明白为什么在那里而不是在[rootfolder]/node_modules/grunt-steroids/node_modules所以避免与其他 grunt 插件(或其他)冲突?

These are installed in [rootfolder]/node_modules, and I don't understand why there and not in [rootfolder]/node_modules/grunt-steroids/node_modules so that conflicts with other grunt plugins (or whatever) are avoided?

推荐答案

TL;DR: peerDependencies 用于暴露于(并预期由) 消费代码,而不是私有" 依赖项,这些依赖项没有公开,只是一个实现细节.

TL;DR: peerDependencies are for dependencies that are exposed to (and expected to be used by) the consuming code, as opposed to "private" dependencies that are not exposed, and are only an implementation detail.

NPM 的模块系统是分层的.简单场景的一大优势是,当您安装 npm 包时,该包会带来自己的依赖项,因此它可以开箱即用.

NPM's module system is hierarchical. One big advantage for simpler scenarios is that when you install an npm package, that package brings its own dependencies with it so it will work out of the box.

但是在以下情况下会出现问题:

But problems arise when:

  • 您的项目和您正在使用的某个模块都依赖于另一个模块.
  • 这三个模块必须相互通信.

假设您正在构建 YourCoolProject,并且您正在使用 JacksModule 1.0JillsModule 2.0.让我们假设 JacksModule 也依赖于 JillsModule,但是在不同的版本上,比如 1.0.只要这两个版本不符合,就没有问题.JacksModule 在表面之下使用 JillsModule 的事实只是一个实现细节.我们将 JillsModule 捆绑两次,但是当我们获得开箱即用的稳定软件时,这是一个很小的代价.

Let's say you are building YourCoolProject and you're using both JacksModule 1.0 and JillsModule 2.0. And let's suppose that JacksModule also depends on JillsModule, but on a different version, say 1.0. As long as those 2 versions don't meet, there is no problem. The fact that JacksModule is using JillsModule below the surface is just an implementation detail. We are bundling JillsModule twice, but that's a small price to pay when we get stable software out of the box.

但是现在如果 JacksModule 以某种方式暴露其对 JillsModule 的依赖会怎样.例如,它接受 JillsClass 的实例......当我们使用库的 2.0 版本创建一个 new JillsClass 并将其传递时会发生什么jacksFunction?所有的地狱都会崩溃!像 jillsObject instanceof JillsClass 这样简单的东西会突然返回 false 因为 jillsObject 实际上是 another JillsClass 的一个实例2.0 版本.

But now what if JacksModule exposes its dependency on JillsModule in some way. It accepts an instance of JillsClass for example... What happens when we create a new JillsClass using version 2.0 of the library and pass it along to jacksFunction? All hell will break loose! Simple things like jillsObject instanceof JillsClass will suddenly return false because jillsObject is actually an instance of another JillsClass, the 2.0 version.

他们告诉 npm

我需要这个包,但我需要属于项目,而不是我的模块专用的某个版本.

I need this package, but I need the version that is part of the project, not some version private to my module.

当 npm 发现你的包被安装到一个没有依赖项的项目中,或者它有一个不兼容的版本时,它会警告用户在安装过程中.

When npm sees that your package is being installed into a project that does not have that dependency, or that has an incompatible version of it, it will warn the user during the installation process.

  • 当您正在构建供其他项目使用的库时,
  • 这个库正在使用其他库,
  • 您希望/需要用户也使用其他库

常见场景是大型框架的插件.想想 Gulp、Grunt、Babel、Mocha 等.如果您编写 Gulp 插件,您希望该插件与用户项目使用的 Gulp 相同,而不是与您自己的 Gulp 私有版本一起使用.

Common scenarios are plugins for larger frameworks. Think of things like Gulp, Grunt, Babel, Mocha, etc. If you write a Gulp plugin, you want that plugin to work with the same Gulp that the user's project is using, not with your own private version of Gulp.

这篇关于为什么在 npm 中为插件使用对等依赖项?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆