Devez-vous valider le dossier node_modules dans Git?

C'est une bonne question à avoir. Il y a des avantages et des inconvénients. Je discute du sujet pour que vous puissiez vous faire votre propre opinion.

Devez-vous valider le dossier node_modules dans Git?

Je mentionne Git mais il en va de même pour tout système de contrôle de version que vous utilisez

C'est une bonne question à avoir. Il y a des avantages et des inconvénients.

Je suggère que la valeur par défaut est dene pasvalidez le dossier node_modules, et ajoutez-le à la place à votre.gitignoredéposer.

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

Je discute du sujet pour que vous puissiez vous faire votre propre opinion.

Voici quelques arguments en faveur de ne pas valider node_modules

Vous gardez votre historique Git propre. Lorsque vous ajoutez un nouveau package, vous stockez lepackage.jsonetpackage-lock.jsonchangements de fichier. Lorsque vous décidez de mettre à jour la version du package, tout ce que vous stockez est lepackage-lock.jsonchangement de fichier.

package-lock.jsonest une fonctionnalité relativement nouvelle de npm, qui rend obsolète lefilm rétractablecommande utilisée dans le passé

Vous évitez d'avoir à mettre éventuellement des centaines de Mo de dépendances dans votre référentiel, ce qui signifie qu'avec le temps, il sera plus rapide de travailler avec. Changer de branche et extraire le code sont deux opérations très affectées par la taille du référentiel.

Lorsque vous travaillez avec des branches, vous pouvez avoir des conflits de fusion qui s'étendent au-delà de votre code et impliquent à la place du code de dépendances. Ce n'est pas agréable à gérer et vous pourriez perdre beaucoup de temps. Éviter de mettre

Une demande d'extraction ou une fusion si vous changez 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 afficher le diff complet (GitHub, par exemple)

Les modules de nœuds natifs doivent être recompilés si vous déployez sur une plate-forme différente de votre machine de développement (cas d'utilisation courant: vous développez sur Mac, déployez sur Linux). Vous devez appelernpm rebuild, ce qui désynchronise le serveur.

Ne pas valider node_modules implique que vous devez lister tous vos modules dans lepackage.json(etpackage-lock.json) comme étape obligatoire. C'est génial, car vous n'avez peut-être pas la diligence nécessaire pour le faire, et certaines opérations npm pourraient être interrompues si vous ne le faites pas.

Astuce: il n'est pas nécessaire d'utiliser la version spécifique dans votrepackage.jsonfichier, pas plus depuis l'introduction dupackage-lock.jsondéposer.

Si vous utilisez desdependenciesetdevDependenciesensembles, en validant lenode_modulesdossier que vous validez essentiellementdevDependencieset il n'y a pas de moyen (facile) pour la version de production de s'en débarrasser.

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

Unenpmpackage peut être supprimé par son auteur du registre npm. C'est arrivé avec le célèbreleft-pad incident in 2016 (Lire la suite). Ceci est très rare pour les packages populaires. Si cela se produit, vous n'aurez peut-être plus accès à cette fonctionnalité particulière.

Vous pourriez également affirmer quenpmn'est pas garanti de rester indéfiniment, il pourrait disparaître, donc un moyen simple de garantir d'avoir le code complet de votre application à l'avenir est de le valider avec votre application.

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

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

Vous pouvez utiliser un serveur de référentiel privé pour votre projet et l'utiliser pour héberger toutes vos dépendances.

Les options comprennent

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

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

La solution optimale consiste soit à soumettre un PR qui fait ce que vous voulez pour le projet d'origine, soit à le fork et à utiliser votre fork comme dépendance.

Téléchargez mon gratuitManuel de Node.js


Plus de didacticiels sur les nœuds:


Tech Wiki en ligne!