Quelle est la différence entre les dépendances, devDependencies et peerDependencies dans le fichier npm package.json ?

Question

Cette documentation répond très mal à ma question. Je n'ai pas compris ces explications. Quelqu'un peut-il le dire avec des mots plus simples ? Peut-être avec des exemples si c'est difficile de choisir des mots simples ?

EDIT également ajouté peerDependencies qui est étroitement lié et peut prêter à confusion.

Answer 1

Résumé des différences de comportement importantes :

• dependencies sont installés sur les deux :

  • npm install à partir d'un répertoire qui contient package.json
  • npm install $package sur tout autre répertoire

• devDependencies sont :

  • également installé sur npm install sur un répertoire qui contient package.json sauf si vous passez l'option --production flag (go upvote La réponse de Gayan Charith ).
  • non installé sur npm install "$package" sur n'importe quel autre répertoire, à moins que vous ne lui donniez le statut de --dev option.
  • ne sont pas installés de manière transitive.

• peerDependencies :

  • avant 3.0 : sont toujours installés s'ils sont manquants, et lèvent une erreur si plusieurs versions incompatibles de la dépendance seraient utilisées par différentes dépendances.
  • devrait commencer sur 3.0 (non testé) : donner un avertissement si manquant sur npm install et vous devez résoudre la dépendance vous-même manuellement. Lors de l'exécution, si la dépendance est manquante, vous obtenez une erreur (mentionnée par @nextgentech ) Ceci l'explique très bien : https://flaviocopes.com/npm-peer-dependencies/
  • dans la version 7 Les peerDependencies sont automatiquement installées à moins qu'un conflit de dépendance en amont ne soit présent et ne puisse être résolu automatiquement.

• Transitivité (mentionnée par Ben Hutchison ) :

  • dependencies sont installés de manière transitive : si A nécessite B, et que B nécessite C, alors C est installé, sinon, B ne pourrait pas fonctionner, et A non plus.

  • devDependencies n'est pas installé de manière transitive. Par exemple, nous n'avons pas besoin de tester B pour tester A, donc les dépendances de test de B peuvent être laissées de côté.

Options connexes non abordées ici :

• bundledDependencies qui est discuté à la question suivante : Avantages de bundledDependencies par rapport aux dépendances normales dans npm
• optionalDependencies (mentionné par Aidan Feldman )

devDependencies

dependencies sont nécessaires pour fonctionner, devDependencies uniquement pour développer, par exemple : tests unitaires, transpilation de CoffeeScript en 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.json et exécuter :

npm install

Puisque vous avez la source réelle, il est clair que vous voulez la développer, donc par défaut, les deux dependencies (puisqu'il faut, bien sûr, courir pour développer) et devDependency sont également installées.

Si toutefois, vous n'êtes qu'un utilisateur final qui souhaite simplement installer un paquet pour l'utiliser, vous le ferez à partir de n'importe quel répertoire :

npm install "$package"

Dans ce cas, vous ne voulez normalement pas les dépendances de développement, vous obtenez donc juste ce qui est nécessaire pour utiliser le paquet : dependencies .

Si vous voulez vraiment installer les paquets de développement dans ce cas, vous pouvez définir l'option dev option de configuration pour true éventuellement à partir de la ligne de commande comme :

npm install "$package" --dev

L'option est false par défaut, car il s'agit d'un cas beaucoup moins fréquent.

peerDependencies

(Testé avant 3.0)

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

Avec les dépendances normales, vous pouvez avoir plusieurs versions de la dépendance : elle est simplement installée à l'intérieur de la section node_modules de la dépendance.

Par exemple, si dependency1 et dependency2 dépendent tous deux de dependency3 à différentes versions, l'arbre du projet ressemblera à ceci :

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

Les plugins, quant à eux, sont des paquets qui ne nécessitent normalement pas l'autre paquet, qui est appelé le hôte dans ce contexte. Au lieu de cela :

• les plugins sont nécessaires 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 avoir une seule version de celui-ci.

Par exemple, si dependency1 et dependency2 pairs dépendent de dependency3 l'arbre du projet ressemblera à ceci :

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

Cela arrive même si vous ne mentionnez jamais dependency3 dans votre package.json fichier.

Je pense que c'est un exemple de la Inversion du contrôle modèle de conception.

Un exemple prototypique 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 le verrez :

• 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 exigera implicitement le plugin de la base de données de l'utilisateur. Gruntfile en ajoutant un grunt.loadNpmTasks('grunt-contrib-uglify') ligne, mais c'est grunt que l'utilisateur appellera directement.

Cela ne fonctionnerait pas alors si chaque plugin nécessitait une version différente de Grunt.

Manuel

Je pense que la documentation répond assez bien à la question, peut-être que vous n'êtes tout simplement pas assez familier avec node / d'autres gestionnaires de paquets. Je ne le comprends probablement que parce que je connais un peu le bundler de Ruby.

La ligne clé est :

Ces éléments seront installés lors de l'exécution de npm link ou npm install à partir de la racine d'un paquet et peuvent être gérés comme tout autre paramètre de configuration de npm. Voir npm-config(7) pour plus d'informations sur le sujet.

Et ensuite sous npm-config(7) trouvez dev :

Default: false
Type: Boolean

Install dev-dependencies along with packages.

Answer 2

Si vous ne voulez pas installer devDependencies vous pouvez utiliser npm install --production

Answer 3

Dépendances
Les dépendances dont votre projet a besoin pour fonctionner, comme une bibliothèque qui fournit des fonctions que vous appelez depuis votre code.
Ils sont installés de manière transitive (si A dépend de B dépend de C, npm install on A installera B et C).
Exemple : lodash : votre projet appelle certaines fonctions lodash.

devDependencies
Les dépendances dont vous n'avez besoin que pendant le développement ou la publication, comme les compilateurs qui prennent votre code et le compilent en javascript, les cadres de test ou les générateurs de documentation.
Ils ne sont pas installés de manière transitive (si A dépend de B dev-depends de C, npm install on A installera uniquement B).
Exemple : grunt : votre projet utilise grunt pour se construire.

peerDependencies
Dépendances que votre projet accroche, ou modifie, dans le projet parent, généralement un plugin pour une autre bibliothèque ou un autre outil. Il s'agit simplement d'une vérification, pour s'assurer que le projet parent (projet qui dépendra de votre projet) a une dépendance sur le projet auquel vous vous accrochez. Ainsi, si vous créez un plugin C qui ajoute une fonctionnalité à la bibliothèque B, la personne qui crée un projet A devra avoir une dépendance sur B si elle a une dépendance sur C.
Ils ne sont pas installés (sauf si npm < 3), ils sont seulement vérifiés.
Exemple : grunt : votre projet ajoute une fonctionnalité à grunt et ne peut être utilisé que sur des projets qui utilisent grunt.

Cette documentation explique très bien les dépendances entre pairs : https://nodejs.org/en/blog/npm/peer-dependencies/

De plus, la documentation de npm a été améliorée au fil du temps, et contient désormais de meilleures explications sur les différents types de dépendances : https://github.com/npm/cli/blob/latest/docs/content/configuring-npm/package-json.md#devdependencies

Answer 4

Par exemple, mocha serait normalement une devDependency, puisque les tests ne sont pas nécessaires en production, alors qu'express serait une dependency.

Answer 5

Pour sauvegarder un paquet dans paquet.json en tant que dépendances dev :

npm install "$package" --save-dev

Lorsque vous exécutez npm install il installera les deux devDependencies et dependencies . Pour éviter d'installer devDependencies courir :

npm install --production