为什么要在npm中将对等依赖项用于插件? [英] Why use peer dependencies in npm for plugins?
问题描述
例如，为什么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/
Peer dependencies are described here: https://nodejs.org/en/blog/npm/peer-dependencies/
但是我真的不明白.
示例
Example
此刻，我正在使用AppGyver Steroids，它使用Grunt任务将我的源文件构建到/dist/文件夹中，以便在本地设备上提供服务.我在npm上很新，很咕gr，所以我想完全理解发生了什么.
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: [1] peerDependencies用于暴露于(和预计将由使用方代码使用，而不是未公开的私有" 依赖项，而仅仅是实现细节.
TL;DR:[1] 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.0和JillsModule 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实际上是另一个 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.
- 在构建供其他项目使用的库时，和
- 该库正在使用其他库和
- 您希望/也需要用户与该其他库一起使用
- When you are building a library to be used by other projects, and
- This library is using some other library, and
- You expect/need the user to work with that other library as well
常见方案是用于较大框架的插件.想想诸如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屋！
