Npm nous permet de spécifier bundledDependencies mais quels sont les avantages d'une telle démarche ? Je suppose que nous voulons être absolument sûrs d'obtenir la bonne version même si le module que nous référençons est supprimé, ou peut-être y a-t-il un avantage en termes de vitesse avec le regroupement ?
Quelqu'un connaît-il les avantages de bundledDependencies par rapport aux dépendances normales ?
Pour le lecteur rapide : ce QA concerne le paquet.json champ bundledDependencies, pas sur le paquet .
Les "bundledDependencies" sont exactement ce que leur nom indique. Les dépendances qui devraient se trouver dans votre projet. Leur fonctionnalité est donc fondamentalement la même que celle des dépendances normales. Elles seront également empaquetées lors de l'exécution de npm pack .
Les dépendances normales sont généralement installées à partir du registre npm. Ainsi, les dépendances groupées sont utiles lorsque :
Ainsi, vous n'avez pas besoin de créer (et de maintenir) votre propre dépôt npm, mais vous bénéficiez des mêmes avantages que les paquets npm.
Lors du développement, je ne pense pas que le but principal soit d'empêcher les mises à jour accidentelles. Nous avons de meilleurs outils pour cela, à savoir les dépôts de code (git, mercurial, svn...) ou maintenant les fichiers de verrouillage.
Pour épingler les versions de vos paquets, vous pouvez utiliser :
Option1 : Utilisez la nouvelle version 5 de NPM qui est fournie avec node 8. Il utilise un package-lock.json (voir le blog de noeud et la version du nœud 8)
Option2 : utilice fils au lieu de npm . C'est un gestionnaire de paquets de facebook, plus rapide que npm et il utilise un yarn.lock fichier. Il utilise le même package.json autrement.
Ceci est comparable à la loc ou Cargo. Il est similaire à npm-shrinkwrap.json de npm, mais il n'y a pas de perte de données. perte et permet d'obtenir des résultats reproductibles.
npm a en fait copié cette fonctionnalité de yarn entre autres.
npm shrinkwrap la plupart du temps, et parfois mettre le tout, y compris le dossier node_module, dans votre dépôt de code. Ou éventuellement utiliser sac à dos rétractable . Les meilleures pratiques de l'époque ont été discutées sur le site Web de la Commission européenne. blog node.js et sur le développeur joyeux sites web.Cela sort un peu du cadre de la question, mais j'aimerais mentionner le dernier type de dépendances (que je connais) : dépendances entre pairs . Voir aussi Question connexe sur le SO et éventuellement les docs de yarn sur bundledDependencies .
L'un des plus gros problèmes actuels de Node est la rapidité avec laquelle il évolue. Cela signifie que les systèmes de production peuvent être très fragiles et une npm update peut facilement casser des choses.
L'utilisation de bundledDependencies est un moyen de contourner ce problème en garantissant, comme vous le supposez, que vous fournirez toujours les bonnes dépendances, quels que soient les autres changements.
Vous pouvez également l'utiliser pour regrouper vos propres paquets privés et les livrer avec l'installation.
L'autre avantage est que vous pouvez y placer vos dépendances internes (composants d'application) et les demander dans votre application comme s'il s'agissait de modules indépendants au lieu d'encombrer votre lib/ et de les publier sur npm.
Si/quand ils sont mûrs au point de pouvoir vivre comme des modules séparés, vous pouvez les mettre sur npm facilement, sans modifier votre code.
Je suis surpris de ne pas l'avoir déjà vu ici, mais lorsqu'il est sélectionné avec soin, bundledDependencies peut être utilisé pour produire un paquet distribuable à partir de npm pack qui fonctionnera sur un système où npm n'est pas configuré. Ceci est utile si vous avez par exemple un système qui n'est pas en réseau / pas sur Internet : apportez votre paquet sur une clé USB (ou autre) et décompressez l'archive tarball, ensuite npm run ou node index.js et ça marche.
Il existe peut-être un meilleur moyen de regrouper votre application pour qu'elle fonctionne "hors ligne", mais s'il en existe un, je ne l'ai pas trouvé.
D'un point de vue opérationnel, je considère bundledDependencies comme le magasin de modules privé d'un module, alors que dependencies est plus public, résolu entre votre module et ses dépendances (et sous-dépendances). Votre module peut s'appuyer sur une version plus ancienne de, disons, react, mais une dépendance exige la dernière et la meilleure. Votre paquetage/installation aura pour résultat votre version épinglée en node_modules/$yourmodule/node_modules/react tandis que vos dépendances obtiendront leur version dans le fichier node_modules/react (ou node_modules/$dependency/node_modules/react s'ils en ont envie).
Une mise en garde : j'ai récemment rencontré une dépendance qui ne configurait pas correctement sa dépendance à react, et le fait d'avoir react dans bundledDependencies faisait échouer ce module dépendant au moment de l'exécution.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
