Resumen de importantes diferencias de comportamiento:
Opciones relacionadas no discutidas aquí:
devDependencies
dependenciesson necesarios para ejecutar, devDependenciessolo para desarrollar, por ejemplo: pruebas unitarias, CoffeeScript a JavaScript, recopilación, minificación, ...
Si va a desarrollar un paquete, descárguelo (por ejemplo, a través de git clone), vaya a su raíz que contiene package.jsony ejecute:
npm install
Como tiene la fuente real, está claro que desea desarrollarla, por lo que, de manera predeterminada, tanto dependencies(como debe, por supuesto, ejecutar para desarrollar) como las devDependencydependencias también están instaladas.
Sin embargo, si solo es un usuario final que solo desea instalar un paquete para usarlo, lo hará desde cualquier directorio:
npm install "$package"
En ese caso, normalmente no quieren las dependencias de desarrollo, por lo que acaba de obtener lo que se necesita para usar el paquete: dependencies.
Si realmente desea instalar paquetes de desarrollo en ese caso, puede establecer la devopción de configuración true, posiblemente desde la línea de comandos como:
npm install "$package" --dev
La opción es falsepor defecto ya que este es un caso mucho menos común.
Dependencias
(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 node_modulesde la dependencia.
Por ejemplo, si dependency1y dependency2ambos dependen de dependency3versiones diferentes, 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 denomina host en este contexto. En lugar:
- el host requiere complementos
- los complementos ofrecen una interfaz estándar que el anfitrión espera encontrar
- solo el host será llamado directamente por el usuario, por lo que debe haber una única versión del mismo.
Por ejemplo, si dependency1y por dependency2pares dependen dependency3, el árbol del proyecto se verá así:
root/node_modules/
|
+- dependency1/
|
+- dependency2/
|
+- dependency3 v1.0/
Esto sucede aunque nunca lo mencione dependency3en su package.jsonarchivo.
Creo que esta es una instancia del patrón de diseño de Inversión de control .
Un ejemplo prototípico de dependencias entre pares es Grunt, el host y sus complementos.
Por ejemplo, en un complemento de Grunt como https://github.com/gruntjs/grunt-contrib-uglify , verá que:
grunt es un peer-dependency- el único
require('grunt')está debajo tests/: el programa no lo utiliza realmente.
Luego, cuando el usuario usará un complemento, implícitamente requerirá el complemento al Gruntfileagregar una grunt.loadNpmTasks('grunt-contrib-uglify')línea, pero es gruntque el usuario llamará directamente.
Esto no funcionaría si cada complemento requiriera una versión diferente de Grunt.
Manual
Creo que la documentación responde bastante bien a la pregunta, tal vez no esté tan familiarizado con los nodos / otros gestores de paquetes. Probablemente solo lo entiendo porque sé un poco sobre el paquete Ruby.
La línea clave es:
Estas cosas se instalarán al hacer el enlace npm o la instalación npm desde la raíz de un paquete y se pueden administrar como cualquier otro parámetro de configuración npm. Consulte npm-config (7) para obtener más información sobre el tema.
Y luego en npm-config (7) encuentra dev:
Default: false
Type: Boolean
Install dev-dependencies along with packages.
optionalDependenciesahora.