Dépendances homologues NPM en profondeur : une introduction complète

En tant que développeurs Javascript, nous connaissons tous deux dépendances différentes dans nos projets, les dépendances et les devDependencies, mais qu'en est-il des peerDependencies ?

Dans cette série, nous examinerons cette dépendance moins courante en Javascript. Nous étudierons de quoi il s'agit, ce que je dois savoir en tant qu'utilisateur de bibliothèque et quelles sont les meilleures pratiques pour les auteurs de bibliothèque.

Que sont les dépendances dans NPM

Récapitulons les différents types courants :

• dépendances : ce sont les outils utilisés dans votre application ; un bon exemple est réagir, angulaire et express. Lorsque votre application est en production, le code des bibliothèques sur les dépendances fonctionnera sous le capot et alimentera votre application.

• devDependencies : Vous utiliserez ces utilitaires pour créer votre application. Ici, vous trouverez des bibliothèques pour compiler ou analyser votre code et des bibliothèques pour exécuter votre test.

Que sont les dépendances entre pairs

Les auteurs spécifient des bibliothèques spécifiques comme peerDependency lorsqu'ils exigent qu'elles soient installées dans l'espace de travail/le projet pour que tout fonctionne comme prévu. Ils indiquent à NPM (et aux développeurs installant la bibliothèque) que le package nécessite la version spécifique (ou la plage de versions) d'un autre package pour fonctionner correctement. Néanmoins, l'utilisateur est responsable de l'installation et de la gestion de cette dépendance.

Imaginons un exemple : vous créez un utilitaire pour votre framework préféré, qui doit être installé dans l'environnement dans lequel votre bibliothèque sera exécutée. La façon de spécifier avec précision ce scénario consiste à utiliser la fonctionnalité NPM peerDependency. Il fournit des lignes directrices claires pour l'intégration transparente de votre bibliothèque.

Cette pratique est particulièrement courante dans les bibliothèques qui fonctionnent comme des « plugins », car elles doivent indiquer les exigences de l'espace de travail pour fonctionner correctement.

Exemple réel de dépendance entre pairs

Analysons une bibliothèque React populaire, React-datepicker ; si nous regardons à quoi ressemble son package.json aujourd'hui, nous pouvons dire que nous avons besoin au moins de la version React ^16.9.0 pour que le sélecteur de date de réaction fonctionne correctement.

"peerDependencies": {
  "react": "^16.9.0 || ^17 || ^18",
  "react-dom": "^16.9.0 || ^17 || ^18"
},

Si nous ne respectons pas cette exigence, un comportement inattendu surviendra.

Les défis auxquels les pairsDépendances répondent

Des conflits de versions se produisent lorsque les packages d'un projet reposent sur différentes versions de la même bibliothèque. Cela peut entraîner des erreurs, en particulier pour les bibliothèques comme React, où le partage de la même instance est crucial pour la gestion des états et la communication des composants. Sans peerDependencies, plusieurs versions de bibliothèque pourraient être installées, entraînant un comportement inattendu.

Pour éviter ces problèmes, les peerDependencies permettent aux auteurs de packages de spécifier la version d'une dépendance requise par leur package sans l'installer directement. Cela transfère la responsabilité au développeur utilisant le package, garantissant qu'il installe une version de dépendance unique et compatible. Par exemple, des bibliothèques comme React-datepicker et React-Router utilisent peerDependencies pour garantir qu'elles fonctionnent de manière transparente avec la même version de React dans le projet.

Un autre exemple

Imaginez ce scénario : vous créez une bibliothèque pour partager un opérateur sophistiqué pour rxjs. Si vous définissez rxjs comme dépendance au lieu d'une peerDependency, votre bibliothèque installera sa propre version de rxjs. Cela peut ne pas sembler grave au premier abord, mais en réalité, cela peut conduire à des conflits de versions.

Si le projet qui installe votre bibliothèque utilise déjà une version différente de rxjs, cela pourrait entraîner des problèmes importants. L'application peut se retrouver avec deux instances de rxjs (une de votre bibliothèque et une du projet lui-même). Étant donné que rxjs s'appuie fortement sur des observables et des abonnements partagés, l'exécution simultanée de deux versions peut entraîner un comportement imprévisible, tel que des flux ne se synchronisant pas correctement ou des événements manquants.

En utilisant peerDependencies à la place, vous pouvez éviter ce problème. Votre package signalera au projet qu'il s'attend à ce qu'une version spécifique (ou une plage) de rxjs soit présente, mais il n'installera pas sa propre version. De cette façon, le projet utilisera une version unique de rxjs partagée par votre bibliothèque et d'autres parties de la base de code, garantissant que tout se déroule sans problème et en harmonie.

Conclusion

Les dépendances peerDependencies ne sont peut-être pas aussi couramment évoquées que les dépendances ou les dépendances dev, mais elles jouent un rôle essentiel pour garantir la compatibilité et éviter les conflits de versions dans les projets complexes. En définissant clairement la version d'une dépendance partagée dont une bibliothèque a besoin sans l'installer directement, les peerDependencies permettent aux développeurs de garder le contrôle sur l'environnement de leur projet.

Le but de ce premier article est de créer une bonne base de compréhension des peerDependencies. Dans le prochain chapitre de cette série, nous explorerons de manière plus pratique les différents aspects des peerDependencies en tant qu'utilisateur de bibliothèques avec peerDependencies, comment surmonter les problèmes courants et comment ils se comportent dans différents gestionnaires de packages javascript.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!