Le dossier “node_modules” doit-il être inclus dans le repository git?

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

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 repository git est un choix viable et quelle alternative vous choisissez dépend de votre projet.

Parce qu’il a très bien argumenté contre node_modules, je me concentrerai sur les arguments pour eux.

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 consommé par d’autres utilisateurs (par exemple, vous créez une application Web), vous devez toujours vérifier les packages installés dans le contrôle des sources.»

Les détails des modules sont stockés dans packages.json , cela suffit. Il n’est pas nécessaire de vérifier les 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 qui impliquent des extensions natives ne fonctionneront pas avec l’architecture et devront ê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 tels que PhantomJS et node-sass par exemple, qui installent le binary approprié pour le système actuel.

Cela signifie que si un développeur exécute npm install sur Linux et vérifie node_modules – cela ne fonctionnera pas pour un autre développeur qui clone le repository sous Windows.

Il est préférable de vérifier les archives qui installent les téléchargements npm-shrinkwrap.json et de leur indiquer npm-shrinkwrap.json . Vous pouvez automatiser ce processus en utilisant shrinkpack .

Ne pas suivre node_modules avec le contrôle de source est le bon choix car certains modules NodeJS, comme le pilote MongoDB NodeJS, utilisent des additifs NodeJS C ++. Ces modules complémentaires sont compilés lors de l’exécution de la commande npm install . Ainsi, lorsque vous node_modules répertoire node_modules , vous pouvez commettre accidentellement un fichier binary spécifique au système d’exploitation.

Une autre chose à prendre en compte: vérifier dans node_modules rend plus difficile / impossible d’utiliser la différence entre les dependencies et les devDependencies .

D’un autre côté, on pourrait dire qu’il est rassurant de pousser à la production exactement le même code qui a passé les tests, y compris les devDependencies .

node_modules n’a pas besoin d’être enregistré si des dépendances sont mentionnées dans package.json. Tout autre programmeur peut simplement l’obtenir en effectuant l’installation npm et le npm est assez intelligent pour créer les modules_noeud dans votre répertoire de travail pour le projet.