Le dossier "node_modules" doit-il être inclus dans le dépôt git ?

Question

Je me demande si nous devons suivre les node_modules dans notre repo ou faire une installation npm lorsque nous vérifions le code ?

Answer 1

La réponse n'est pas aussi simple que Alberto Zaccagni suggère . Si vous développez des applications (en particulier des applications d'entreprise), l'inclusion de node_modules dans votre repo git est un choix viable. La solution que vous choisissez dépend de votre projet.

Comme il a très bien argumenté contre les node_modules, je vais me concentrer sur les arguments en leur faveur.

Imaginez que vous venez de terminer une application d'entreprise et que vous devrez la soutenir pendant 3 à 5 ans. Vous ne voulez certainement pas dépendre du module npm de quelqu'un qui peut disparaître demain et vous ne pourrez plus mettre à jour votre application.

Ou vous avez vos modules privés qui ne sont pas accessibles depuis l'internet et vous ne pouvez pas construire votre application sur l'internet. Ou peut-être que vous ne voulez pas dépendre de votre build final sur le service npm pour une raison quelconque.

Vous pouvez trouver des avantages et des inconvénients dans cet article d'Addy Osmani (bien qu'il s'agisse de Bower, c'est presque la même situation). Et je terminerai par une citation de la page d'accueil de Bower et de l'article d'Addy :

"Si vous n'êtes pas l'auteur d'un paquet destiné à être consommé par d'autres (par exemple, vous construisez une application web), vous devez toujours vérifier les paquets installés dans le contrôle de source."

Answer 2

Les détails des modules sont stockés dans packages.json c'est suffisant. Il n'y a pas besoin de vérifier node_modules .

Les gens avaient l'habitude de stocker node_modules dans le contrôle de version pour verrouiller les dépendances des modules, mais avec npm shrinkwrap qui n'est plus nécessaire.

Une autre justification de ce point, comme l'a écrit @ChrisCM dans le commentaire :

Il convient également de noter que tous les modules qui impliquent des extensions natives ne fonctionneront pas d'une architecture à l'autre et devront être reconstruits. Fournir une justification concrète pour NE PAS les inclure dans le repo.

Answer 3

Je vous déconseille de vérifier dans node_modules à cause de paquets comme PhantomJS et node-sass par exemple, qui installent le binaire approprié pour le système actuel.

Cela signifie que si un Dev court npm install sur Linux et vérifie dans node_modules - cela ne fonctionnera pas pour un autre Dev qui clone le repo sur Windows.

Il est préférable de vérifier dans les tarballs que npm install télécharge et d'indiquer npm-shrinkwrap.json sur eux. Vous pouvez automatiser ce processus en utilisant sac à dos rétractable .

Answer 4

Ce sujet est assez ancien, je vois. Mais il me manque une mise à jour des arguments fournis ici en raison de l'évolution de la situation dans l'éco-système de NPM.

Je conseillerais toujours de ne pas mettre les node_modules sous contrôle de version. Presque tous les avantages de le faire, tels qu'ils sont énumérés dans le contexte de la réponse acceptée, sont plutôt dépassés à l'heure actuelle.

1. Les paquets publiés ne peuvent plus être révoqués du registre NPM aussi facilement. Vous n'avez donc pas à craindre de perdre les dépendances sur lesquelles votre projet s'appuyait auparavant.

2. Le fait de placer le fichier package-json.lock dans le VCS est utile pour les dépendances fréquemment mises à jour, ce qui entraîne probablement des configurations différentes bien que reposant sur le même fichier package.json.

Ainsi, l'intégration de node_modules dans VCS en cas d'utilisation d'outils de construction hors ligne peut être considérée comme le seul cas d'utilisation admissible restant. Cependant, node_modules se développe généralement assez rapidement. Toute mise à jour modifie un grand nombre de fichiers. Et cela affecte les dépôts de différentes manières. Si l'on considère vraiment les effets à long terme, cela peut également constituer un obstacle.

Les VCS centralisés comme svn requièrent le transfert des fichiers validés et extraits sur le réseau, ce qui est extrêmement lent lorsqu'il s'agit d'extraire ou de mettre à jour un dossier node_modules.

Lorsqu'il s'agit de git, ce nombre élevé de fichiers supplémentaires pollue instantanément le dépôt. Gardez à l'esprit que git ne suit pas les différences entre les versions d'un fichier, mais stocke des copies de chaque version d'un fichier dès qu'un seul caractère a changé. Chaque mise à jour d'une dépendance entraînera un autre grand jeu de modifications. Votre dépôt git va rapidement devenir énorme à cause de cela, ce qui affecte les sauvegardes et la synchronisation à distance. Si vous décidez de supprimer node_modules du dépôt git ultérieurement, il en fait toujours partie pour des raisons historiques. Si vous avez distribué votre dépôt git sur un serveur distant (par exemple, pour la sauvegarde), le nettoyer est une autre tâche pénible et sujette aux erreurs.

Ainsi, si vous êtes soucieux de l'efficacité des processus et aimez garder les choses "petites", je préférerais utiliser un dépôt d'artefacts séparé tel que le dépôt Nexos (ou simplement un serveur HTTP avec des archives ZIP) fournissant un ensemble de dépendances préalablement récupérées pour le téléchargement.

Answer 5

Pas de suivi node_modules avec contrôle de la source est le bon choix car certains modules NodeJS, comme le pilote MongoDB NodeJS, utilisent des modules complémentaires NodeJS C++. Ces modules complémentaires sont compilés lors de l'exécution de npm install commandement. Ainsi, lorsque vous suivez node_modules vous pouvez accidentellement livrer un fichier binaire spécifique au système d'exploitation.