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


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


1460
2017-09-18 14:57


origine


Réponses:


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 dans tout autre répertoire
  • devDependencies sont:

    • également installé sur npm install dans un répertoire contenant package.json, sauf si vous passez le --production drapeau (aller upvote La réponse de Gayan Charith).
    • pas installé sur npm install "$package" dans tout autre répertoire, sauf si vous lui donnez le --dev option.
    • ne sont pas installés de manière transitive.
  • peerDependencies:

    • avant la version 3.0: sont toujours installés s'ils sont manquants et déclenchent une erreur si plusieurs versions incompatibles de la dépendance sont utilisées par des dépendances différentes.
    • prévu à partir de 3.0 (non testé): donner un avertissement s'il manque npm install, et vous devez résoudre la dépendance manuellement. Lors de l'exécution, si la dépendance est manquante, vous obtenez une erreur (mentionnée par @nextgentech)
  • Transitivité (mentionné par Ben Hutchison):

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

    • devDependencies ne sont pas installés 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 omises.

Options connexes non abordées ici:

devDependencies

dependencies sont nécessaires pour courir, devDependencies seulement pour développer, par exemple: tests unitaires, Coffeescript à Javascript transpilation, minification, ...

Si vous développez un package, vous le téléchargez (par exemple via git clone), allez à sa racine qui contient package.json, et courir:

npm install

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

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

npm install "$package"

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

Si vous voulez vraiment installer des packages de développement dans ce cas, vous pouvez définir dev option de configuration pour true, peut-être à partir de la ligne de commande comme:

npm install "$package" --dev

L'option est false par défaut puisque c'est un cas beaucoup moins commun.

peerDependencies

(testé avant 3.0)

La 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 dans le node_modulesde la dépendance.

Par exemple. si dependency1 et dependency2 les deux dépendent de dependency3 à différentes versions, l'arborescence du projet ressemblera à:

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

Les plugins sont cependant des paquets qui ne nécessitent normalement pas l'autre paquet, appelé 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 dependency1 et dependency2 pair dépend de dependency3, l'arborescence du projet ressemblera à:

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

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

Je pense que c'est une instance du Inversion de contrôle design pattern.

Un exemple prototypique de dépendances entre homologues 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 peerDependency
  • le seul require('grunt') est sous tests/: ce n'est pas réellement utilisé par le programme.

Ensuite, lorsque l'utilisateur utilisera un plugin, il impliquera implicitement le plugin de la Gruntfile en ajoutant un grunt.loadNpmTasks('grunt-contrib-uglify') ligne, mais c'est grunt que l'utilisateur appellera directement.

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

Manuel

Je pense que le doc répond assez bien à la question, peut-être que vous n'êtes pas assez familier avec les gestionnaires de paquets / nœuds. Je ne le comprends probablement que parce que je connais un peu le bundler Ruby.

La ligne clé est:

Ces éléments seront installés lors de l'installation de npm link ou npm à partir de la racine d'un paquet, 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.

1739
2018-02-25 04:25



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


361
2017-07-05 10:06



A titre d'exemple, moka serait normalement une dépendance de type Dev, car le test n'est pas nécessaire en production, alors que Express serait une dépendance.


91
2017-09-18 18:39



Pour enregistrer un package dans package.json comme dev dépendances:

npm install "$package" --save-dev

Lorsque vous courez npm install il va installer les deux devDependencies et dependencies. Pour éviter l'installation devDependencies courir:

npm install --production

48
2018-01-08 06:41



Certains modules et paquets sont uniquement nécessaires au développement, qui ne sont pas nécessaires en production. Comme il le dit dans le Documentation:

Si quelqu'un envisage de télécharger et d'utiliser votre module dans son programme, alors il ne veut probablement pas ou ne doit pas télécharger et construire le test externe ou le cadre de documentation que vous utilisez. Dans ce cas, il est préférable de lister ces éléments supplémentaires dans un hachage devDependencies.


29
2017-09-18 14:59



dépendances
Les dépendances que votre projet doit exécuter, comme une bibliothèque qui fournit des fonctions que vous appelez à partir de votre code.
Ils sont installés de manière transitive (si A dépend de B dépend de C, l'installation de npm sur A installera B et C).
Exemple: lodash: votre projet appelle des fonctions lodash.

devDependencies
Dépendances dont vous avez seulement besoin pendant le développement ou la libération, comme les compilateurs qui prennent votre code et le compilent en javascript, frameworks de test ou générateurs de documentation.
Ils ne sont pas installés de façon transitive (si A dépend de B dev-dépend de C, l'installation de npm sur A installera B uniquement).
Exemple: grunt: votre projet utilise grunt pour se construire.

peerDependencies
Dépendances que votre projet croise ou modifie dans le projet parent, généralement un plugin pour une autre bibliothèque ou un autre outil. Il est juste destiné à être une vérification, en s'assurant que le projet parent (projet qui dépendra de votre projet) dépend du projet auquel vous vous connectez. Donc, si vous créez un plugin C qui ajoute des fonctionnalités à la bibliothèque B, alors quelqu'un qui crée un projet A devra avoir une dépendance sur B s'il a une dépendance sur C.
Ils ne sont pas installés (à moins que npm <3), ils sont seulement vérifiés.
Exemple: grunt: votre projet ajoute des fonctionnalités à grogner et ne peut être utilisé que sur des projets utilisant grunt.

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

En outre, la documentation NPM a été améliorée au fil du temps, et a maintenant de meilleures explications sur les différents types de dépendances: https://github.com/npm/npm/blob/master/doc/files/package.json.md#devdependencies


18
2017-09-05 17:27



Une explication simple qui me l'a fait comprendre est:

Lorsque vous déployez votre application, les modules dans les dépendances doivent être installés ou votre application ne fonctionnera pas. Les modules de devDependencies n'ont pas besoin d'être installés sur le serveur de production car vous ne développez pas sur cette machine. lien


8
2017-09-29 15:36



Je voudrais ajouter à la réponse mon point de vue sur ces explications de dépendances

  • dependencies sont utilisés pour une utilisation directe dans votre base de code, les éléments qui finissent généralement dans le code de production, ou des morceaux de code
  • devDependencies sont utilisés pour le processus de construction, des outils qui vous aident à gérer la fin du code de fin, des modules de test de tierces parties (par exemple, des paquets webpack)

6
2018-02-16 11:40



Lorsque vous essayez de distribuer un paquet npm, vous devez éviter d'utiliser dependencies. Au lieu de cela, vous devez envisager de l'ajouter dans peerDependencies ou retirez-le de dependencies.


0
2017-07-06 12:47