Parfois, nous pouvons trouver les définitions suivantes dans le fichier package.json :
{
//...
"peerDependencies": {
"libraryName": "1.x"
}
}
dependenciesest le package dont dépend notre projet.
devDependenciesest un package nécessaire pendant la phase de développement. Disons par exemple un framework de test comme Jest ou d'autres utilitaires comme Babel ou ESLint.
Dans les deux cas, lorsque nous installons un package, npm installe automatiquement ses dependencieset devDependencies.
peerDependencies fonctionne différemment. Ils sont 不会installés automatiquement.
Lorsqu'une dépendance ( dependency) est répertoriée en tant que peerDependency dans un package, elle n'est pas automatiquement installée. Au lieu de cela, le code d'application qui inclut ce package doit l'inclure en tant que dépendance.
Voir un exemple.
Le package.json du projet a contient le projet b :
{
//...
"dependencies": {
"b": "1.x"
}
}
package.json pour le projet b :
{
//...
"peerDependencies": {
"c": "1.x"
}
}
Donc, dans le package A, nous devons ajouter c en tant que dépendance, sinon lorsque vous installez le package b, npm lancera un avertissement (et le code peut échouer lors de l'exécution):
a's package.json :
{
//...
"dependencies": {
"b": "1.x",
"c": "1.x"
}
}
Un problème avec peerDependencies :
Si mon package dépend de la version 2 de la requête et d'autres bibliothèques, mais que d'autres bibliothèques dépendent de la version 1 de la requête, le graphique de dépendance résultant ressemble à ceci :
Désormais, some-other-library a sa propre copie v1 des requêtes, sans interférer avec la copie v2 du propre package de requêtes de l'application.
En résumé, les dépendances entre pairs ressemblent presque à des dépendances normales, mais au lieu de définir des exigences fortes entre A et B (c'est-à-dire le projet que vous développez et les projets dont il dépend), elles sont conçues pour spécifier les packages dont votre code a besoin, mais ne l'exige pas directement.
Imaginez que nous développions le module A qui est un plugin pour le module B. Cela signifie que A sera utilisé avec B, et pour cela, A doit suivre une certaine structure et très probablement avoir une API publique conforme aux critères suivants pour être appelée à partir des méthodes de B.
//in your code...
B.addPlugin(new A())
//....
B.method() //internally using A's code here.