Le 2021 JavaScript Full-Stack Bootcamp est MAINTENANT OUVERT POUR LES INSCRIPTIONS !

Devriez-vous commettre le dossier node_modules à Git ?

Je mentionne Git mais la même chose s’applique à n’importe quel système de contrôle de version qu’il vous arrive d’utiliser

C’est une bonne question à se poser. Il y a des avantages et des inconvénients.

Je suggère que le défaut est de ne pas commiter le dossier node_modules, et de l’ajouter plutôt à votre fichier .gitignore.

Vous pourriez avoir des besoins spéciaux qui renversent cette décision.

J’aborde le sujet pour que vous puissiez vous faire votre propre opinion.

Voici quelques arguments en faveur de ne pas commiter node_modules

Vous gardez votre historique Git propre. Lorsque vous ajoutez un nouveau paquet, vous stockez les changements de fichiers package.json et package-lock.json.Lorsque vous décidez de mettre à jour la version du paquet, tout ce que vous stockez est le changement de fichier package-lock.json.

package-lock.json est une fonctionnalité relativement nouvelle de npm, qui supprime la commande shrinkwrap utilisée dans le passé

Vous évitez d’avoir à mettre éventuellement des centaines de Mo de dépendances dans votre dépôt, et cela signifie qu’avec le temps, il sera plus rapide de travailler avec. Le changement de branche et le check out du code sont 2 opérations énormément affectées par la taille du dépôt.

Lorsque vous travaillez avec des branches, vous pouvez avoir des conflits de fusion qui s’étendent au-delà de votre code, et au lieu de cela, impliquent le code des dépendances. Ce n’est pas agréable à gérer et pourrait vous faire perdre beaucoup de temps. Éviter de mettre

Une pull request ou une fusion si on change les dépendances, va avoir beaucoup plus de fichiers impliqués dans le processus. Les outils deviennent plus lents ou même décident de ne pas montrer le diff complet (GitHub, par exemple)

Les modules node natifs doivent être recompilés si vous déployez sur une plateforme différente de votre machine de développement(cas d’utilisation courant : vous développez sur Mac, déployez sur Linux). Vous devez appeler npm rebuild, ce qui désynchronise le serveur.

Ne pas commettre node_modules implique que vous devez lister tous vos modules dans le package.json (et package-lock.json) comme une étape obligatoire. C’est génial parce que vous pourriez ne pas avoir la diligence de le faire, et certaines des opérations npm pourraient se briser si vous ne le faites pas.

Tip : il n’est pas nécessaire d’utiliser la version spécifique dans votre fichier package.json, plus depuis l’introduction du fichier package-lock.json.

Si vous utilisez des ensembles dependencies et devDependencies séparés, en commettant le dossier node_modules, vous commettez fondamentalement le devDependencies et il n’y a pas de moyen (facile) pour le build de production de s’en débarrasser.

Raisons qui pourraient vous amener à commettre des node_modules, et comment les atténuer

Un paquet npm pourrait être retiré par son auteur du registre npm. C’est arrivé avec le célèbre incident left-pad en 2016 (lire la suite). Il est très rare que cela se produise pour des paquets populaires. Si cela se produit, vous pourriez ne plus avoir accès à cette pièce particulière de la fonctionnalité.

Vous pourriez également faire valoir que npm n’est pas garanti de rester autour indéfiniment, il pourrait disparaître, donc un moyen facile de garantir d’avoir le code complet de votre application à l’avenir est de le commettre avec votre application.

Chaque fois que vous utilisez un paquet, créez un fork sur GitHub. De temps en temps, mettez-le à jour avec l’origine (peut être automatisé).

Ce n’est pas toujours pratique car les paquets peuvent avoir des dizaines de leurs propres dépendances.

Vous pouvez utiliser un serveur de dépôt privé pour votre projet, et l’utiliser pour héberger toutes vos dépendances.

Les options comprennent

• sinopia
• npm_lazy
• npm-lazy-mirror
• artifactory
• npm Enterprise, de la société npm

Une autre raison de commettre les dépendances est la possibilité de modifier rapidement le code, si vous trouvez un bug ou si vous voulez ajouter quelque chose à une bibliothèque.

C’est une arme à double tranchant : si vous le faites, vous perdez la possibilité de mettre à jour le paquet si de nouvelles versions sont faites, et c’est juste bon pour des corrections rapides et temporaires.

La solution optimale est soit de soumettre un PR qui fait ce que vous voulez au projet original, soit de le forker et d’utiliser votre fork comme dépendance.

Le 2021 JavaScript Full-Stack Bootcamp EST MAINTENANT OUVERT AUX INSCRIPTIONS JUSQU’AU MARDI PROCHAIN ! Ne manquez pas cette opportunité, inscrivez-vous AUJOURD’HUI !

Plus de tutoriels sur Node :

• Comment utiliser les promises et les await avec les fonctions basées sur les callbacks de Node.js
• Les modules de base de Node
• Parcourir JSON avec Node.js
• Travailler avec les descripteurs de fichiers dans Node
• Node.js Streams
• Comment obtenir la dernière date de mise à jour d’un fichier en utilisant Node.js
• Le Guide du Carlin
• Avoir le dossier actuel dans Node
• Comment utiliser le REPL de Node.js

.