Réponses:
La réponse n'est pas aussi simple que le suggère Alberto Zaccagni. Si vous développez des applications (en particulier des applications d'entreprise), inclure node_modules dans votre dépôt git est un choix viable et l'alternative que vous choisissez dépend de votre projet.
Parce qu'il a très bien argumenté contre node_modules, je me concentrerai sur leurs arguments.
Imaginez que vous venez de terminer l'application d'entreprise et que vous devrez 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 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 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 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 code source."
git checkout foo. Si node_modules n'est pas sous VCS - le changement de branche est git checkout foo ; npm installet tout ce que votre version actuelle de NPM requiert pour fonctionner;)
Les détails des modules sont stockés packages.json, cela suffit. Il n'est pas nécessaire de s'enregistrer node_modules.
Les gens avaient l'habitude de stocker node_modulesdans 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 l'écrit @ChrisCM dans le commentaire:
Il convient également de noter que tous les modules qui impliquent des extensions natives ne fonctionneront pas d'architecture en architecture et doivent être reconstruits. Fournir une justification concrète pour ne PAS les inclure dans le repo.
Je recommanderais de ne pas enregistrer node_modules à cause de packages comme PhantomJS et node-sass par exemple, qui installent le binaire approprié pour le système actuel.
Cela signifie que si un Dev s'exécute npm installsous Linux et enregistre node_modules - cela ne fonctionnera pas pour un autre Dev qui clone le dépôt sous Windows.
Il est préférable de vérifier les archives tar que npm installe les téléchargements et de les pointer npm-shrinkwrap.json. Vous pouvez automatiser ce processus à l'aide de shrinkpack .
npm install --global shrinkpacklui-même alors la faiblesse différée, en exigeant d'autres paquets avec lesquels installer ensuite les paquets rétrécis? Cela va à l'encontre des conseils d'Addy.
shrinkpackest requise pour ensuite installer de manière fiable les dépendances de génération. Par conséquent, l'installation de l'outil de construction lui-même devient la faiblesse de l'argument contre la soumission de toutes les dépendances de construction au contrôle de version.
Ce sujet est assez ancien, je vois. Mais il me manque une mise à jour des arguments fournis ici en raison du changement de situation dans l'écosystème de npm.
Je conseillerais toujours de ne pas mettre node_modules sous contrôle de version. Presque tous les avantages de le faire comme énumérés dans le contexte de la réponse acceptée sont assez obsolètes pour le moment.
Les packages publiés ne peuvent plus être révoqués aussi facilement du registre npm. Vous n'avez donc pas à craindre de perdre les dépendances sur lesquelles votre projet s'est appuyé auparavant.
Mettre le fichier package-json.lock dans VCS aide avec 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 en cas d'outils de construction hors ligne peut être considéré comme le seul cas d'utilisation éligible restant. Cependant, node_modules se développe généralement assez rapidement. Toute mise à jour modifiera 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 sera lent comme l'enfer lorsqu'il s'agira d'extraire ou de mettre à jour un dossier node_modules.
En ce qui concerne git, ce nombre élevé de fichiers supplémentaires polluera instantanément 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 changé. Chaque mise à jour d'une dépendance entraînera un autre ensemble de modifications volumineux. Votre référentiel git deviendra rapidement énorme à cause de cela affectant les sauvegardes et la synchronisation à distance. Si vous décidez de supprimer node_modules du référentiel git plus tard, 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), le nettoyer est une autre tâche pénible et sujette aux erreurs que vous rencontrez.
Ainsi, si vous vous souciez des processus efficaces et que vous aimez garder les choses «petites», je préfère utiliser un référentiel d'artefacts séparé tel que Nexos Repository (ou juste un serveur HTTP avec des archives ZIP) fournissant un ensemble de dépendances précédemment récupéré pour le téléchargement.
Ne pas suivre node_modulesavec le contrôle de code 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 la npm installcommande. Ainsi, lorsque vous suivez le node_modulesrépertoire, vous pouvez commettre accidentellement un fichier binaire spécifique au système d'exploitation.
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, ce ne sera pas un problème pour vous. Si vous n'avez que le nom du package dans package.json, vous ne pouvez plus l'obtenir. Si un package a moins de 24 heures, vous pouvez facilement le supprimer de npm. S'il a 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 risquerait d'interrompre les autres installations. Si tel est le cas, nous ne le supprimerons pas.
Les chances pour cela sont donc faibles, mais il y a le scénario 2 ...
scénario 2:
Un autre scénario où c'est le cas: Vous développez une version 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 package.
Maintenant, les développeurs de studpid-package renomment la méthode function1(x)en function2(x)et ils font une erreur ... Ils changent la version de leur package de 1.0.1en 1.1.0. C'est un problème car lorsque vous appelez npm installla prochaine fois, vous accepterez la version 1.1.0car vous avez utilisé le tilde ( "studpid-package": "~1.0.1").
L'appel function1(x)peut provoquer des erreurs et des problèmes maintenant.
Mais:
Le fait de pousser tout le dossier node_modules (souvent plus de 100 Mo) vers votre référentiel vous coûtera de l'espace mémoire. Quelques Ko (package.json uniquement) contre des centaines de Mo (package.json & node_modules) ... Pensez-y.
Vous pourriez le faire / devriez y penser si:
le logiciel est très important.
cela vous coûte de l'argent quand quelque chose échoue.
vous ne faites pas confiance au registre npm. npm est centralisé et pourrait théoriquement être arrêté.
Vous n'avez pas besoin de publier le dossier node_modules dans 99,9% des cas si:
vous développez un logiciel rien que pour vous.
vous avez programmé quelque chose et souhaitez simplement publier le résultat sur GitHub car quelqu'un d'autre pourrait peut-être être intéressé.
Si vous ne voulez pas que les node_modules soient dans votre référentiel, créez simplement un .gitignorefichier et ajoutez la ligne node_modules.
npm installsous Windows et MacOS pourrait générer des fichiers différents (fichiers dépendant du système d'exploitation) dans certains packages. Mais je n'en suis pas sûr. Quelqu'un peut-il vérifier que c'est vrai?
package-lock.json. S'il y a un problème à l'avenir avec une mise à jour de studpid-package, vous pouvez restaurer le fichier de verrouillage pour connaître la version exacte qui a fonctionné pour vous.
Je voudrais proposer une alternative à mi-chemin.
node_modulesdans git.package-lock.jsonfichier pour définir vos versions de dépendance.Dans le cas rare où vous ne pouvez pas accéder à NPM (ou à d'autres registres que vous utilisez) ou à un package spécifique dans NPM, vous disposez d'une copie de node_modules et pouvez continuer à travailler jusqu'à ce que vous restauriez l'accès.
Une dernière chose à considérer: l'enregistrement node_modulesrend plus difficile / impossible d'utiliser la différence entre dependencieset devDependencies.
D'un autre côté, on pourrait dire qu'il est rassurant de pousser à la production exactement le même code qui a subi des tests - y compris devDependencies.