¿Por qué, por ejemplo, un complemento de Grunt define su dependencia de Grunt como " dependencias entre pares "?

¿Por qué el complemento no puede tener Grunt como su propia dependencia en grunt-plug / node_modules ?

Las dependencias entre pares se describen aquí: https://nodejs.org/en/blog/npm/peer-dependencies/

Pero realmente no lo entiendo.

Ejemplo

Estoy trabajando con AppGyver Steroids en este momento, que utiliza tareas de Grunt para construir mis archivos de origen en una carpeta / dist / para que se sirvan en un dispositivo local. Soy bastante nuevo en npm y gruñido, así que quiero comprender completamente lo que está sucediendo.

Hasta ahora entiendo esto:

[rootfolder] /package.json le dice a npm que depende del grunt-steroidspaquete npm para el desarrollo:

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

Bueno. La ejecución de npm install en [rootfolder] detecta la dependencia e instala grunt-steroids en [rootfolder] / node_modules / grunt-steroids .

Npm luego lee [rootfolder] /node_modules/grunt-steroids/package.json para que pueda instalar sus grunt-steroidspropias dependencias .:

"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"
  },

Los paquetes de " dependencias " se instalan en [rootfolder] / node_modules / grunt-steroids / node_modules, lo cual es lógico para mí.

Las " devDependencies " no están instaladas, lo que estoy seguro es controlado por npm detectando que solo estoy tratando de usar grunt-steroids, y no desarrollarlo.

Pero luego tenemos las " dependencias de pares ".

Estos se instalan en [rootfolder] / node_modules , y no entiendo por qué allí y no en [rootfolder] / node_modules / grunt-steroids / node_modules para evitar conflictos con otros plugins grunt (o lo que sea).

TL; DR: ^[1] peerDependencies son para dependencias que están expuestas (y se espera que sean utilizadas por) el código consumidor, a diferencia de las dependencias "privadas" que no están expuestas, y son solo un detalle de implementación.

El problema que resuelven las dependencias entre pares

El sistema de módulos de NPM es jerárquico. Una gran ventaja para escenarios más simples es que cuando instala un paquete npm, ese paquete trae consigo sus propias dependencias para que funcione de manera inmediata.

Pero surgen problemas cuando:

• Tanto su proyecto como algún módulo que esté utilizando dependen de otro módulo.
• Los tres módulos tienen que hablar entre ellos.

Por ejemplo

Digamos que estás construyendo YourCoolProjecty estás usando ambos JacksModule 1.0y JillsModule 2.0. Y supongamos que eso JacksModuletambién depende JillsModule, pero en una versión diferente, digamos 1.0. Mientras esas 2 versiones no cumplan, no hay problema. El hecho de que JacksModulese use JillsModuledebajo de la superficie es solo un detalle de implementación. Estamos agrupando JillsModuledos veces, pero ese es un pequeño precio a pagar cuando sacamos el software estable de la caja.

Pero ahora, ¿qué JacksModulepasa si expone su dependencia de JillsModulealguna manera? Acepta una instancia de, JillsClasspor ejemplo ... ¿Qué sucede cuando creamos una new JillsClassversión 2.0de uso de la biblioteca y se la pasamos jacksFunction? ¡Todo el infierno se desatará! Cosas simples como jillsObject instanceof JillsClassregresarán repentinamente falseporque en jillsObjectrealidad es una instancia de otra JillsClass , la 2.0versión.

Cómo las dependencias de pares resuelven esto

Dicen npm

Necesito este paquete, pero necesito la versión que forma parte del proyecto, no alguna versión privada de mi módulo.

Cuando npm ve que su paquete se está instalando en un proyecto que no tiene esa dependencia, o que tiene una versión incompatible , advertirá al usuario durante el proceso de instalación.

¿Cuándo deberías usar las dependencias entre pares?

• Cuando está construyendo una biblioteca para ser utilizada por otros proyectos, y
• Esta biblioteca está utilizando alguna otra biblioteca y
• Usted espera / necesita que el usuario trabaje con esa otra biblioteca también

Los escenarios comunes son complementos para marcos más grandes. Piense en cosas como Gulp, Grunt, Babel, Mocha, etc. Si escribe un complemento Gulp, desea que ese complemento funcione con el mismo Gulp que está utilizando el proyecto del usuario, no con su propia versión privada de Gulp.

Anotaciones

1. Demasiado largo; No leí. Se usa para indicar un breve resumen de un texto que se ha considerado demasiado largo.

Le recomendaría que lea el artículo nuevamente primero. Es un poco confuso, pero el ejemplo con winston-mail le muestra la respuesta por qué:

Por ejemplo, supongamos que se [email protected]especifica "winston": "0.5.x"en su "dependencies"objeto porque esa es la última versión con la que se probó. Como desarrollador de aplicaciones, quieres lo último y lo mejor, así que buscas las últimas versiones de winstony de winston-maily las colocas en tu package.json como

{
  "dependencies": {  
    "winston": "0.6.2",  
    "winston-mail": "0.2.3"  
  }  
}

Pero ahora, ejecutar npm install da como resultado el gráfico de dependencia inesperado de

├── winston@0.6.2  
└─┬ winston-mail@0.2.3                
  └── winston@0.5.11

En este caso, es posible tener múltiples versiones de un paquete que causarían algunos problemas. Las dependencias entre pares permiten a los desarrolladores de npm asegurarse de que el usuario tenga el módulo específico (en la carpeta raíz). Pero tiene razón con el punto de que describir una versión específica de un paquete generaría problemas con otros paquetes que usan otras versiones. Este problema tiene que ver con los desarrolladores de npm, como dicen los artículos

Un consejo : los requisitos de dependencia entre pares, a diferencia de los de las dependencias regulares, deben ser indulgentes . No debe bloquear sus dependencias pares a versiones de parche específicas.

Por lo tanto, los desarrolladores deben seguir semver para definir las peerDependencies. Debería abrir un problema para el paquete de esteroides grunt en GitHub ...

peerDependencies explicado con el ejemplo más simple posible:

{
  "name": "myPackage",
  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }
}


{
  "name": "foo"
  "peerDependencies": {
    "react": "^16.0.0"
  }
}

ejecutar npm install en myPackage arrojará un error porque está intentando instalar la versión React ^15.0.0Y fooque solo es compatible con React ^16.0.0.

Las dependencias peer NO están instaladas.