Résumé des différences de comportement importantes:
Options connexes non discutées ici:
devDependencies
dependenciessont nécessaires pour exécuter, devDependenciesuniquement pour développer, par exemple: tests unitaires, transpilation CoffeeScript vers JavaScript, minification, ...
Si vous allez développer un paquet, vous le téléchargez (par exemple via git clone), allez à sa racine qui contient package.jsonet exécutez:
npm install
Puisque vous avez la source réelle, il est clair que vous souhaitez la développer, donc par défaut, à la fois dependencies(puisque vous devez, bien sûr, exécuter pour développer) et les devDependencydépendances sont également installés.
Si toutefois vous n'êtes qu'un utilisateur final qui souhaite simplement installer un package pour l'utiliser, vous le ferez à partir de n'importe quel répertoire:
npm install "$package"
Dans ce cas, vous ne voulez pas normalement les dépendances de développement, de sorte que vous obtenez juste ce qu'il faut pour utiliser le package: dependencies.
Si vous voulez vraiment installer des packages de développement dans ce cas, vous pouvez définir l' devoption de configuration sur true, éventuellement à partir de la ligne de commande comme:
npm install "$package" --dev
L'option est falsepar défaut car il s'agit d'un cas beaucoup moins courant.
peerDependencies
(Testé avant 3.0)
Source: https://nodejs.org/en/blog/npm/peer-dependencies/
Avec les dépendances régulières, vous pouvez avoir plusieurs versions de la dépendance: elle est simplement installée à l'intérieur node_modulesde la dépendance.
Par exemple, si dependency1et les dependency2deux dépendent de dependency3versions différentes, l'arborescence du projet ressemblera à:
root/node_modules/
|
+- dependency1/node_modules/
| |
| +- dependency3 v1.0/
|
|
+- dependency2/node_modules/
|
+- dependency3 v2.0/
Les plugins, cependant, sont des packages qui ne nécessitent normalement pas l'autre package, qui est appelé l' hôte dans ce contexte. Au lieu:
- les plugins sont requis par l'hôte
- les plugins offrent une interface standard que l'hôte s'attend à trouver
- seul l'hôte sera appelé directement par l'utilisateur, il doit donc y en avoir une seule version.
Par exemple, si dependency1et les dependency2pairs en dépendent dependency3, l'arborescence du projet ressemblera à:
root/node_modules/
|
+- dependency1/
|
+- dependency2/
|
+- dependency3 v1.0/
Cela se produit même si vous ne le mentionnez jamais dependency3dans votre package.jsonfichier.
Je pense que ceci est une instance du modèle de conception d' inversion de contrôle .
Un exemple prototype de dépendances entre pairs est Grunt, l'hôte et ses plugins.
Par exemple, sur un plugin Grunt comme https://github.com/gruntjs/grunt-contrib-uglify , vous verrez que:
grunt est un peer-dependency- le seul
require('grunt')est sous tests/: il n'est pas réellement utilisé par le programme.
Ensuite, lorsque l'utilisateur utilisera un plugin, il aura implicitement besoin du plugin depuis Gruntfileen ajoutant une grunt.loadNpmTasks('grunt-contrib-uglify')ligne, mais c'est gruntque l'utilisateur appellera directement.
Cela ne fonctionnerait pas si chaque plugin nécessitait une version Grunt différente.
Manuel
Je pense que la documentation répond assez bien à la question, peut-être que vous n'êtes pas assez familier avec les gestionnaires de nœuds / autres packages. Je ne le comprends probablement que parce que je connais un peu le bundle Ruby.
La ligne clé est:
Ces éléments seront installés lors de la liaison npm ou de l'installation npm à partir de la racine d'un package et peuvent être gérés comme n'importe quel autre paramètre de configuration npm. Voir npm-config (7) pour plus d'informations sur le sujet.
Et puis sous npm-config (7) trouver dev:
Default: false
Type: Boolean
Install dev-dependencies along with packages.
optionalDependenciesmaintenant.