Pregunta ¿Cuál es la diferencia entre dependencias, devDependencies y peerDependencies en el archivo npm package.json?


Esta documentación responde mi pregunta muy mal. No entendí esas explicaciones. ¿Alguien puede decir en palabras más simples? ¿Tal vez con ejemplos si es difícil elegir palabras simples?


1460
2017-09-18 14:57


origen


Respuestas:


Resumen de las diferencias de comportamiento importantes:

  • dependencies están instalados en ambos:

    • npm install desde un directorio que contiene package.json
    • npm install $package en cualquier otro directorio
  • devDependencies son:

    • también instalado en npm install en un directorio que contiene package.json, a menos que pase el --production bandera (ir arriba La respuesta de Gayan Charith)
    • no instalado en npm install "$package" en cualquier otro directorio, a menos que le des el --dev opción.
    • no están instalados transitivamente.
  • peerDependencies:

    • before 3.0: siempre se instalan si faltan, y generan un error si varias dependencias usan versiones incompatibles de la dependencia.
    • esperado a partir de 3.0 (no probado): dar una advertencia si falta en npm install, y usted tiene que resolver la dependencia usted mismo de forma manual. Cuando se ejecuta, si la dependencia falta, se obtiene un error (mencionado por @nextgentech)
  • Transitividad (mencionado por Ben Hutchison)

    • dependencies se instalan transitoriamente: si A requiere B y B requiere C, entonces C se instala; de lo contrario, B no podría funcionar, y tampoco A.

    • devDependencies no están instalados transitivamente. P.ej. no necesitamos probar B para probar A, entonces las dependencias de prueba de B pueden ser dejadas de lado.

Opciones relacionadas no discutidas aquí:

devDependencies

dependencies están obligados a correr, devDependencies solo para desarrollar, p. ej .: pruebas unitarias, transcripción de Coffeescript a Javascript, minificación, ...

Si vas a desarrollar un paquete, lo descargas (por ejemplo, a través de git clone), vaya a su raíz que contiene package.json, y correr:

npm install

Como tiene la fuente real, está claro que desea desarrollarla, por lo tanto, por defecto ambos dependencies (dado que debe, por supuesto, correr para desarrollarse) y devDependency las dependencias también están instaladas.

Sin embargo, si solo es un usuario final que solo quiere instalar un paquete para usarlo, lo hará desde cualquier directorio:

npm install "$package"

En ese caso, normalmente no desea las dependencias de desarrollo, por lo que solo obtiene lo que necesita para usar el paquete: dependencies.

Si realmente desea instalar paquetes de desarrollo en ese caso, puede configurar el dev opción de configuración para true, posiblemente desde la línea de comando como:

npm install "$package" --dev

La opción es false por defecto, ya que este es un caso mucho menos común.

peerDependencies

(probado antes de 3.0)

Fuente: https://nodejs.org/en/blog/npm/peer-dependencies/

Con dependencias regulares, puede tener múltiples versiones de la dependencia: simplemente se instala dentro del node_modulesde la dependencia

P.ej. Si dependency1 y dependency2 ambos dependen de dependency3 en diferentes versiones, el árbol del proyecto se verá así:

root/node_modules/
                 |
                 +- dependency1/node_modules/
                 |                          |
                 |                          +- dependency3 v1.0/
                 |
                 |
                 +- dependency2/node_modules/
                                            |
                                            +- dependency3 v2.0/

Sin embargo, los complementos son paquetes que normalmente no requieren el otro paquete, que se llama anfitrión en este contexto. En lugar:

  • Se requieren complementos por el anfitrión
  • los complementos ofrecen una interfaz estándar que el host espera encontrar
  • solo el host será llamado directamente por el usuario, por lo que debe haber una única versión del mismo.

P.ej. Si dependency1 y dependency2 par depender de dependency3, el árbol del proyecto se verá así:

root/node_modules/
                 |
                 +- dependency1/
                 |
                 +- dependency2/
                 |
                 +- dependency3 v1.0/

Esto sucede aunque nunca menciones dependency3 en tus package.json archivo.

Creo que esta es una instancia de Inversión de control patrón de diseño.

Un ejemplo prototípico de dependencias entre pares es Grunt, el host y sus complementos.

Por ejemplo, en un plugin de Grunt como https://github.com/gruntjs/grunt-contrib-uglify, verás eso:

  • grunt es un peerDependency
  • lo único require('grunt') está debajo tests/: en realidad no es utilizado por el programa.

Luego, cuando el usuario use un complemento, requerirá implícitamente el complemento del Gruntfile agregando un grunt.loadNpmTasks('grunt-contrib-uglify') línea, pero es grunt que el usuario llamará directamente.

Esto no funcionaría si cada plugin requiriera una versión diferente de Grunt.

Manual

Creo que el documento responde la pregunta bastante bien, quizás no estés lo suficientemente familiarizado con el nodo / otros gestores de paquetes. Probablemente solo lo entiendo porque sé un poco sobre el paquete de Ruby.

La línea clave es:

Estas cosas se instalarán cuando se realice el enlace npm o la instalación de npm desde la raíz de un paquete, y se pueden gestionar como cualquier otro parámetro de configuración npm. Ver npm-config (7) para más sobre el tema.

Y luego bajo npm-config (7) encontrar dev:

Default: false
Type: Boolean

Install dev-dependencies along with packages.

1739
2018-02-25 04:25



Si no quiere instalar devDependencies, simplemente puede usar npm install --production 


361
2017-07-05 10:06



Como ejemplo, mocha normalmente sería un devDependency, ya que la prueba no es necesaria en producción, mientras que express sería una dependencia.


91
2017-09-18 18:39



Para guardar un paquete a paquete.json como dependencias dev:

npm install "$package" --save-dev

Cuando corres npm install instalará ambos devDependencies y dependencies. Para evitar la instalación devDependencies correr:

npm install --production

48
2018-01-08 06:41



Hay algunos módulos y paquetes solo necesarios para el desarrollo, que no son necesarios en la producción. Como dice en el documentación:

Si alguien está planeando descargar y usar su módulo en su programa, entonces probablemente no quiera o necesite descargar y construir el marco de prueba o documentación externo que utiliza. En este caso, es mejor enumerar estos elementos adicionales en un hash de devDependencies.


29
2017-09-18 14:59



dependencias
Dependencias que necesita ejecutar su proyecto, como una biblioteca que proporciona funciones a las que llama desde su código.
Se instalan transitoriamente (si A depende de B, depende de C, la instalación de npm en A instalará B y C).
Ejemplo: lodash: su proyecto llama a algunas funciones lodash.

devDependencies
Dependencias que solo necesita durante el desarrollo o la publicación, como compiladores que toman su código y lo compilan en javascript, marcos de prueba o generadores de documentación.
No se instalan transitoriamente (si A depende de B dev, depende de C, la instalación de npm en A solo instalará B).
Ejemplo: grunt: tu proyecto usa ronco para compilarse.

peerDependencies
Dependencias que su proyecto engancha, o modifica, en el proyecto principal, generalmente un complemento para alguna otra biblioteca o herramienta. Solo tiene la intención de ser un control, asegurándose de que el proyecto principal (proyecto que dependerá de su proyecto) dependa del proyecto al que se conecta. Entonces, si crea un complemento C que agrega funcionalidad a la biblioteca B, entonces alguien que hace un proyecto A tendrá que tener una dependencia en B si tienen una dependencia en C.
No están instalados (a menos que npm <3), solo se verifican.
Ejemplo: gruñido: su proyecto agrega funcionalidad a ronco y solo se puede usar en proyectos que usan ronco.

Esta documentación explica muy bien las dependencias entre pares: https://nodejs.org/en/blog/npm/peer-dependencies/ 

Además, la documentación de npm se ha mejorado con el tiempo, y ahora tiene mejores explicaciones de los diferentes tipos de dependencias: https://github.com/npm/npm/blob/master/doc/files/package.json.md#devdependencies


18
2017-09-05 17:27



Una explicación simple que me dejó más claro es:

Cuando implemente su aplicación, los módulos en dependencias deben estar instalados o su aplicación no funcionará. Los módulos en devDependencies no necesitan instalarse en el servidor de producción ya que no está desarrollando en esa máquina. enlazar


8
2017-09-29 15:36