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

Il existe des modules et des paquets nécessaires uniquement pour le développement, qui ne sont pas nécessaires en production. Comme il est dit dans le documentation :

Si quelqu'un a l'intention de télécharger et d'utiliser votre module dans son programme, il n'a probablement pas envie ou besoin de télécharger et de construire le cadre de test ou de documentation externe que vous utilisez. Dans ce cas, il est préférable de répertorier ces éléments supplémentaires dans un hachage devDependencies.

Answer 2

peerDependencies n'avait pas vraiment de sens pour moi jusqu'à ce que je lise ce passage de un article de blog sur le sujet Ciro mentionné ci-dessus :

Quoi [ plugins Il faut un moyen d'exprimer ces "dépendances" entre les plugins et leur paquetage hôte. Une façon de dire : "Je ne fonctionne que lorsque je suis branché sur la version 1.2.x de mon paquetage hôte, donc si vous m'installez, assurez-vous que c'est avec un hôte compatible". Nous appelons cette relation une dépendance entre pairs.

Le plugin fait s'attendre à une version spécifique de l'hôte...

peerDependencies sont destinés aux plugins, des bibliothèques qui nécessitent une bibliothèque "hôte" pour remplir leur fonction, mais qui peuvent avoir été écrits à un moment donné. avant la dernière version de l'hôte a été publiée.

C'est-à-dire que si j'écris PluginX v1 pour HostLibraryX v3 et s'en aller, il n'y a aucune garantie PluginX v1 fonctionnera lorsque HostLibraryX v4 (ou même HostLibraryX v3.0.1 ) est libéré.

... mais le plugin ne le fait pas. dépendent de sur l'hôte...

Du point de vue du plugin, il ne fait que ajoute à la bibliothèque de l'hôte. Je n'ai pas vraiment "besoin" de l'hôte pour ajouter une dépendance à un plugin, et les plugins n'en ont souvent pas besoin au sens propre du terme. dépendent de sur leur hôte. Si vous n'avez pas l'hôte, le plugin ne fait rien.

Cela signifie que dependencies n'est pas vraiment le bon concept pour les plugins.

Pire encore, si mon hôte était traité comme une dépendance, nous nous retrouverions dans la situation suivante le même article de blog mentionne (modifié un peu pour utiliser l'hôte et le plugin inventés par cette réponse) :

Mais maintenant, [si nous traitons la version contemporaine de HostLibraryX comme une dépendance de PluginX,] l'exécution de la commande npm install donne lieu au graphique de dépendance inattendu de

├── HostLibraryX@4.0.0
└─┬ PluginX@1.0.0
  └── HostLibraryX@3.0.0

Je laisse à votre imagination les échecs subtils dus au fait que le plugin utilise une API [HostLibraryX] différente de celle de l'application principale.

... et l'hôte ne dépend évidemment pas du plugin...

... c'est tout l'intérêt des plugins. Maintenant, si l'hôte était assez gentil pour inclure des informations sur les dépendances de tous de ses plugins, cela résoudrait le problème, mais cela introduirait également un nouveau problème culturel énorme. : gestion des plugins !

L'intérêt des plugins est de pouvoir s'associer de manière anonyme. Dans un monde parfait, l'hôte pourrait gérer tous les plugins, mais nous n'avons pas besoin de bibliothèques pour gérer les chats.

Si nous ne sommes pas hiérarchiquement dépendants, nous sommes peut-être des pairs intradépendants...

Au lieu de cela, nous avons le concept d'être des pairs. Ni l'hôte ni le plugin ne se trouve dans le seau de dépendance de l'autre. Les deux vivent au même niveau du graphe de dépendance.

---

... mais ce n'est pas une relation automatisable. << Moneyball ! !!

Si je suis PluginX v1 et s'attendre à un pair de (c'est-à-dire, ont une PeerDependency de ) HostLibraryX v3 je le dirai. Si vous avez fait une mise à jour automatique vers la dernière HostLibraryX v4 (notez que c'est la version 4 ) ET ont Plugin v1 installé, tu dois savoir, non ?

npm ne peut pas gérer cette situation pour moi

"Hé, je vois que tu utilises PluginX v1 ! Je suis en train de rétrograder automatiquement HostLibraryX de v4 à v3, kk ?"

... ou...

"Hé, je vois que tu utilises PluginX v1 . Cela attend HostLibraryX v3 que vous avez laissé dans la poussière lors de votre dernière mise à jour. Pour être sûr, je désinstalle automatiquement Plugin v1 !!1 !

Et pourquoi pas non, npm ? !

Donc npm ne le fait pas. Il vous avertit de la situation, et vous laisse déterminer si HostLibraryX v4 est un pair approprié pour Plugin v1 .

---

Coda

Bon peerDependency dans les plugins rendra ce concept plus intuitif dans la pratique. À partir de le billet de blog encore une fois...

Un conseil : les exigences en matière de dépendances homologues, contrairement à celles des dépendances ordinaires, doivent être souples. Vous ne devez pas verrouiller vos dépendances par les pairs à des versions de patch spécifiques. Ce serait vraiment ennuyeux si un plugin Chai dépendait de Chai 1.4.1, tandis qu'un autre dépendait de Chai 1.5.0, simplement parce que les auteurs étaient paresseux et n'ont pas pris le temps de déterminer la version minimale de Chai avec laquelle ils sont compatibles.

Answer 3

Une explication simple qui a rendu les choses plus claires pour moi est la suivante :

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

Answer 4

J'ai trouvé une explication simple.

Réponse courte :

Dépendances "...sont ceux dont votre projet a vraiment besoin pour pouvoir fonctionner en production."

devDependencies "...sont ceux dont vous avez besoin pendant le développement."

peerDependencies "si vous voulez créer et publier votre propre bibliothèque afin qu'elle puisse être utilisée comme dépendance"

Plus de détails dans ce post : https://code-trotter.com/web/dependencies-vs-devdependencies-vs-peerdependencies

Answer 5

J'aimerais ajouter à la réponse mon point de vue sur les explications de ces dépendances.

• dependencies sont utilisés pour une utilisation directe dans votre base de code, des choses qui finissent généralement dans le code de production, ou des morceaux de code
• devDependencies sont utilisés pour le processus de construction, les outils qui vous aident à gérer la façon dont le code final se terminera, les modules de test tiers (ex. webpack).