La plupart des services et applications modernes ont une masse de dépendances qui vivent dans un dossier node-modules en croissance constante. En général, beaucoup de ces bibliothèques sont activement maintenues, modifiées et mises à jour. Si vos dépendances sont mal gérées, vous pouvez rapidement vous retrouver dans l’enfer des dépendances.

Si vous n’êtes pas familier avec npm, vérifiez-le ici avant de lire sur

🛒 Épicerie

Lors du démarrage d’une application de nœud, l’une des premières étapes consiste à exécuter npm install. Lorsque vous exécutez cela, node recherchera un fichier appelé package.json dans la base de votre projet. Si ce fichier est trouvé, il utilisera la section dependency comme une sorte de « liste d’épicerie » pour aller chercher des « ingrédients » (bits de code) dont votre application a besoin.

Le « magasin d’épicerie » dans ce cas est quelque chose que npm appelle un registry. Par défaut, votre application node recherchera ces packages dans le registre public npm, où la plupart de tout ce dont vous avez besoin sera (des registres privés peuvent être créés pour du code propriétaire et autres). Si le paquet se trouve dans le registre, node place cet « ingrédient » dans un répertoire node_modules à la base de votre projet.

Il est important de noter que les paquets dont vous avez besoin peuvent avoir leur propre « liste de courses » (paquet.json), et toutes ces dépendances imbriquées doivent être résolues avant que votre application ne passe à la dépendance suivante dans son propre package.json.

⬆️ Versions, CareCarets etcardsWildcards

Les versions de vos dépendances ressemblent généralement à v1.3.5. C’est ce qu’on appelle le versionnage sémantique, ou semver. Avec semver, les nombres représentent les modifications apportées au code de gravité variable – MAJOR.MINOR.PATCH.
De leurs documents –

Version MAJEURE lorsque vous apportez des modifications d’API incompatibles, version mineure
lorsque vous ajoutez des fonctionnalités de manière rétrocompatible et version corrective
lorsque vous effectuez des corrections de bogues rétrocompatibles.

Dans cet esprit, beaucoup de gens veulent mettre à jour automatiquement leur application avec toutes les nouvelles choses que leurs dépendances pourraient avoir dans des modifications plus récentes et sans rupture.

Préfixer avec tilde ~ vous donnera toutes les nouvelles mises à jour PATCH, mais pas majeures ou mineures. Ainsi, ~1.3.1 pourrait installer 1.3.9, mais pas 1.4.0

Le préfixe avec le curseur ^ vous donnera toutes les nouvelles versions PATCH et MINOR, mais pas majeures. Donc ^1.3.1 pourrait installer 1.4.9 mais pas 1.5.0

Jetons un coup d’œil à l’arbre de dépendances de notre exemple de code:

my-breakfast | | milk | |coffee-script 

Ok, plus comme un bâton, mais j’espère que la chaîne de dépendance est claire. Notre forfait.json nécessite la version v0.5.0 spécifiquement de milk, mais milk nécessite coffee-script n’importe où de 0.9.6 à 1.0.0. npm install est exécuté, nous développons notre application, tout est beau.

Now Maintenant, avançons rapidement 2 mois. Quelqu’un trouve votre projet et veut y contribuer. Ils bifurquent et clonent votre dépôt, exécutent npm install, aaaaet cela ne fonctionne pas.  » Mais ça a marché sur ma machine ! » tu pleures. Lorsque votre collaborateur a installé les modules node, on leur a garanti une version spécifique de milk, mais ils ont obtenu une version différente de coffee-script parce que le package de milk.json utilisé semver.

Setting Définir vos dépendances dans stone

Une solution à cela consiste à utiliser un fichier package-lock.json. Ce fichier vous donne un contrôle très granulaire sur les versions de chaque dépendance que vous installez. Si votre package.json est comme la liste de courses, alors votre package-lock.json est comme un budget. Vous pouvez avoir des céréales, mais ce sera une marque de magasin au lieu de Cap’n Crunch. Cette spécificité s’étend jusqu’à chaque branche de votre arbre de dépendance. Vous devez avoir un package.json si vous souhaitez utiliser un fichier de verrouillage (le package.json fait beaucoup plus que la simple gestion des dépendances, c’est juste l’objectif de cet article).

Wrapping Enveloppant

Personnellement, je pense qu’un fichier package-lock.json doit toujours être utilisé (dans les versions plus récentes de npm, il est en fait généré automatiquement). Cela rend tout plus fiable dans tous les environnements et déploiements. Voici quelques dernières petites pépites pour, espérons-le, vous aider en matière de dépendances:

• npm install --save mettra automatiquement à jour votre fichier de verrouillage et votre package.json avec ce paquet.
• npm ci au lieu de seulement npm install reconstruira automatiquement vos modules de nœud et les construira à partir de votre fichier de verrouillage. C’est une commande vraiment utile pour CI / CD et généralement préférable à utiliser en tandem avec un fichier de verrouillage.
• Pour les projets plus importants et les dépendances super robustes, consultez docker et containers. Il peut fonctionner presque comme une machine virtuelle qui contient parfaitement votre code et ses dépendances, et est cloné pour être promu dans différents environnements. J’espère donc que vous vous retrouverez avec beaucoup moins de problèmes « cela a fonctionné sur ma machine ».