206 votes

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

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

4voto

Alpha Points 551

Je suis d'accord avec ivoszz que c'est parfois utile pour vérifier le dossier node_modules, mais ...


scénario 1 :

Un scénario : Vous utilisez un paquet qui a été 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 package.json, vous ne pouvez plus l'obtenir. Si un paquet 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 service d'assistance, il vérifiera si la suppression de cette version de votre paquet n'interrompt pas d'autres installations. Si c'est le cas, nous ne la supprimerons pas.

en savoir plus

Donc les chances pour cela sont 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 paquet.

Maintenant les développeurs de studpid-package ont renommé la méthode function1(x) à function2(x) et ils font une faute... Ils changent la version de leur paquet de 1.0.1 à 1.1.0 . C'est un problème parce que lorsque vous appelez npm install la prochaine fois, vous accepterez la version 1.1.0 parce que vous avez utilisé le tilde ( "studpid-package": "~1.0.1" ).

Appel à function1(x) peut causer des erreurs et des problèmes maintenant.


Mais :

Pousser l'ensemble du dossier node_modules (souvent plus de 100 Mo) vers votre dépôt, vous coûtera de l'espace mémoire. Quelques kb (package.json uniquement) par rapport à des centaines de MB (package.json & node_modules)... Pensez-y.

Vous pourrait le faire / devrait y penser si :

  • le logiciel est très important.

  • ça vous coûte de l'argent quand quelque chose échoue.

  • vous ne faites pas confiance au registre de npm. npm est centralisé et pourrait théoriquement être fermé.

Vous n'ont pas besoin pour publier le dossier node_modules dans 99,9% des cas si :

  • vous développez un logiciel juste pour vous.

  • vous avez programmé quelque chose et vous voulez simplement publier le résultat sur GitHub parce que cela pourrait intéresser quelqu'un d'autre.


Si vous ne voulez pas que les node_modules se trouvent dans votre dépôt, créez simplement un fichier .gitignore et ajoutez la ligne node_modules .

1 votes

Un autre inconvénient de la "publication du dossier node_modules" pourrait être : L'appel à npm install sur Windows et MacOS pouvait générer des fichiers différents (fichiers dépendant de l'OS) dans certains paquets. Mais je n'en suis pas sûr. Quelqu'un peut-il vérifier que c'est vrai ?

2 votes

"scénario 2" : c'est pour cela que vous vous engagez package-lock.json . Si un problème survient à l'avenir avec une mise à jour de studpid-package, vous pouvez revenir en arrière dans le fichier de verrouillage pour retrouver la version exacte qui a fonctionné pour vous.

2voto

Martin Capodici Points 433

Je voudrais proposer une alternative intermédiaire.

  1. N'ajoutez pas node_modules dans git.
  2. Utilisez un package-lock.json pour déterminer les versions de vos dépendances.
  3. Dans votre processus de CI ou de publication, lorsque vous publiez une version, faites une copie du dossier node_modules et sauvegardez-la (par exemple, dans un stockage en nuage).

Dans le cas rare où vous ne pouvez pas accéder à NPM (ou aux autres registres que vous utilisez) ou à un paquet spécifique de NPM, vous disposez d'une copie de node_modules et pouvez continuer à travailler jusqu'à ce que vous rétablissiez l'accès.

0 votes

Cette réponse indique que meilleures pratiques . Bien que le package-lock.json n'est apparu que dans les dernières versions. Peut-être que les premiers implémenteurs de NodeJS n'avaient pas cette méthodologie à l'époque.

0voto

Jan Zankowski Points 1408

Un autre élément à prendre en compte : l'enregistrement 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 mettre en production exactement le même code que celui qui a été testé - donc en incluant devDependencies .

0 votes

"à la production l'exact même code qui est passé par les tests" : C'est pour ça que vous avez Docker. Ou un gestionnaire de paquets, comme rpm. Vous ne reconstruisez pas le code entre test et prod, n'est-ce pas ? devDependencies a aidé à construire le code final, mais n'a pas sa place dans un déploiement, ni en test ni en prod.

0 votes

Cela aiderait-il si les devDependencies étaient dans leur propre package.json, un répertoire plus haut que le répertoire "src" ? Puisque les modules de nœuds sont recherchés en commençant par le répertoire actuel et en remontant ensuite, vous devriez toujours utiliser vos dépendances dev et avoir une séparation des modules dev/src.

0voto

Himanshu Points 1

Node_modules n'est pas obligé d'être vérifié si les dépendances sont mentionnées dans le package.json. Tout autre programmeur peut simplement l'obtenir en faisant npm install et le npm est assez intelligent pour mettre le node_modules dans votre répertoire de travail pour le projet.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X