Le dossier "node_modules" doit-il être inclus dans le référentiel git
Je me demande si nous devrions suivre node_modules dans notre référentiel ou faire une installation npm lors de la vérification du code?
La réponse n'est pas aussi facile que le suggère Alberto Zaccagni. Si vous développez des applications (en particulier des applications d'entreprise), inclure node_modules dans votre référentiel git constitue un choix viable et la solution de votre choix dépend de votre projet.
Parce qu'il a très bien discuté contre node_modules, je vais me concentrer sur les arguments pour eux.
Imaginez que vous venez de terminer l'application d'entreprise et que vous deviez la prendre en charge 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 pouvez plus mettre à jour votre application.
Ou bien vous avez vos modules privés qui ne sont pas accessibles depuis Internet et vous ne pouvez pas créer votre application sur Internet. Ou peut-être que vous ne voulez pas dépendre de votre version finale du service npm pour certaines raisons.
Vous pouvez trouver le pour et le contre dans cet article d'Addy Osmani (bien qu'il s'agisse de Bower, c'est presque la même situation). Et je terminerai avec une citation de la page d'accueil de Bower et l'article d'Addy:
"Si vous ne créez pas un package destiné à être utilisé par d'autres (par exemple, vous créez une application Web), vous devez toujours vérifier les packages installés dans le contrôle de source."
Les détails des modules sont stockés dans packages.json, c'est assez. Il n'y a pas besoin de checkin 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 , ce n’est plus nécessaire.
Une autre justification de ce point, comme @ChrisCM l'a écrit dans le commentaire:
Il convient également de noter que tous les modules impliquant des extensions natives ne fonctionneront pas d'architecture à architecture et doivent être reconstruits. Fournir une justification concrète pour NE PAS les inclure dans le repo.
Je déconseille de vérifier 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 développeur exécute npm install sur Linux et vérifie les nœuds_modules - cela ne fonctionnera pas pour un autre développeur qui clone le référentiel sous Windows
Il est préférable de vérifier dans les archives les fichiers d’installation de npm et de pointer npm-shrinkwrap.json sur eux. Vous pouvez automatiser ce processus en utilisant shrinkpack .
Pas de suivi node_modules _ avec le contrôle de source est le bon choix car certains modules NodeJS, comme le pilote MongoDB NodeJS, utilisent des add-ons NodeJS C++. Ces add-ons sont compilés lors de l'exécution de npm install commande. Alors, quand vous suivez node_modules, vous pouvez accidentellement valider un fichier binaire spécifique au système d'exploitation.
Ce sujet est assez vieux, je vois. Mais il me manque une mise à jour des arguments fournis ici en raison de la modification de la situation dans l'éco système de npm.
Je conseillerais toujours de ne pas mettre node_modules sous contrôle de version. Presque tous les avantages de le faire, énumérés dans le contexte de la réponse acceptée, sont plutôt dépassés à l’heure actuelle.
Les paquets publiés ne peuvent plus être révoqués du registre npm aussi facilement. Vous n’avez donc pas à craindre de perdre des dépendances sur lesquelles votre projet s’appuyait auparavant.
Mettre le fichier package-json.lock dans VCS aide à gérer les dépendances fréquemment mises à jour, ce qui entraîne probablement des configurations différentes tout en s'appuyant sur le même fichier package.json.
Ainsi, placer node_modules dans VCS dans le cas où des outils de construction hors ligne pourraient être considérés comme le seul cas d'utilisation éligible restant. Cependant, node_modules se développe généralement assez rapidement. Toute mise à jour changera beaucoup de fichiers. Et cela affecte les référentiels de différentes manières. Si vous considérez vraiment les effets à long terme, cela pourrait également être un obstacle.
Les VCS centralisés, comme svn, nécessitent le transfert de fichiers validés et extraits sur le réseau, ce qui est extrêmement lent pour extraire ou mettre à jour un dossier node_modules.
Quand il s’agit de git, ce nombre élevé de fichiers supplémentaires va immédiatement polluer le référentiel. Gardez à l'esprit que git ne suit pas les différences entre les versions d'un fichier, mais stocke des copies de l'une ou l'autre version d'un fichier dès qu'un seul caractère a été modifié. Chaque mise à jour d'une dépendance entraîne un autre grand jeu de modifications. Votre référentiel git va rapidement devenir énorme à cause de cela, ce qui affectera les sauvegardes et la synchronisation à distance. Si vous décidez de supprimer node_modules du référentiel git ultérieurement, il en fait toujours partie pour des raisons historiques. Si vous avez distribué votre référentiel git sur un serveur distant (par exemple, pour la sauvegarde), son nettoyage est une autre tâche pénible et sujette aux erreurs que vous auriez à exécuter.
Ainsi, si vous vous souciez de l'efficacité des processus et aimez garder les choses "petites", je préférerais utiliser un référentiel d'artefacts séparé, tel que le référentiel Nexos (ou tout simplement un serveur HTTP avec archives Zip) fournissant un ensemble de dépendances précédemment récupérées pour le téléchargement.
Je suis d'accord avec ivoszz qu'il est parfois utile de vérifier le dossier node_modules, mais ...
scénario 1:
Un scénario: vous utilisez un package qui est supprimé de npm. Si vous avez tous les modules dans le dossier node_modules, alors ce ne sera pas un problème pour vous. Si vous n'avez que le nom du paquet dans le fichier package.json, vous ne pourrez plus le récupérer. Si un colis a moins de 24 heures, vous pouvez facilement le retirer de npm. Si vous avez plus de 24 heures, vous devez les contacter. Mais:
Si vous contactez le support, ils vérifieront si la suppression de cette version de votre package empêcherait d'autres installations. Si c'est le cas, nous ne l'enlèverons pas.
Donc, les chances pour cela sont faibles, mais il y a le scénario 2 ...
scénario 2:
Voici un autre scénario: vous développez une version d'entreprise de votre logiciel ou un logiciel très important et écrivez dans votre package.json:
"dependencies": {
"studpid-package": "~1.0.1"
}
Vous utilisez la méthode function1(x) de ce paquet.
Maintenant, les développeurs de studpid-package renomment la méthode function1(x) en function2(x) et ils commettent une erreur ... Ils modifient la version de leur package de 1.0.1 À 1.1.0. C'est un problème car lorsque vous appelez npm install La prochaine fois, vous acceptez la version 1.1.0 Car vous avez utilisé le tilde ("studpid-package": "~1.0.1").
L'appel de function1(x) peut maintenant causer des erreurs et des problèmes.
Mais:
Le fait de transférer tout le dossier node_modules (souvent plus de 100 Mo) dans votre référentiel vous coûtera de la mémoire. Quelques ko (package.json uniquement) comparés à des centaines de Mo (package.json & node_modules) ... Pensez-y.
Vous pouvez le faire/devriez y penser si:
le logiciel est très important.
cela vous coûte de l'argent en cas d'échec.
vous ne faites pas confiance au registre npm. npm est centralisé et pourrait théoriquement être arrêté.
Vous n'avez pas besoin de pour publier le dossier node_modules dans 99,9% des cas si:
vous développez un logiciel juste pour vous-même.
vous avez programmé quelque chose et souhaitez simplement publier le résultat sur GitHub, car quelqu'un d'autre pourrait peut-être s'y intéresser.
Si vous ne voulez pas que les node_modules soient dans votre référentiel, créez simplement un fichier .gitignore Et ajoutez la ligne node_modules.
node_modules n'a pas besoin d'être archivé si les dépendances sont mentionnées dans package.json. Tout autre programmeur peut simplement l'obtenir en effectuant l'installation de npm et celui-ci est suffisamment intelligent pour rendre les modules node_modules dans votre répertoire de travail du projet.
Une dernière chose à considérer: l'enregistrement dans node_modules rend plus difficile/impossible l’utilisation de la différence entre dependencies et devDependencies.
D'un autre côté, on pourrait dire qu'il est rassurant de transmettre à la production le même code que celui utilisé pour les tests - intégrant ainsi devDependencies.