Dois-je vérifier node_modules pour créer une application node.js sur Heroku?

Deuxième mise à jour

La FAQ n’est plus disponible.

De la documentation de film shrinkwrap :

Si vous souhaitez verrouiller les octets spécifiques inclus dans un package, par exemple pour avoir 100% de confiance dans la capacité de reproduire un déploiement ou une construction, vous devez vérifier vos dépendances dans le contrôle des sources ou suivre un autre mécanisme capable de vérifier contenu plutôt que des versions.

Shannon et Steven ont déjà mentionné cela, mais je pense que cela devrait faire partie de la réponse acceptée.

Mettre à jour

La source répertoriée pour la recommandation ci-dessous a été mise à jour . Ils ne recommandent plus la node_modules dossier node_modules .

Habituellement non. Autoriser npm à résoudre les dépendances pour vos packages.

Pour les packages que vous déployez, tels que les sites Web et les applications, vous devez utiliser npm shrinkwrap pour verrouiller votre arborescence de dépendances complète:

https://docs.npmjs.com/cli/shrinkwrap

Poste d’origine

Pour référence, npm FAQ répond clairement à votre question:

Vérifiez node_modules dans git pour les éléments que vous déployez, tels que les sites Web et les applications. Ne vérifiez pas node_modules dans git pour les bibliothèques et les modules destinés à être réutilisés. Utilisez npm pour gérer les dépendances dans votre environnement de développement, mais pas dans vos scripts de déploiement.

et pour de bonnes raisons, lisez l’article de Mikeal Rogers à ce sujet .

Source: https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git

Mon plus grand souci de ne pas vérifier node_modules dans git est que dans 10 ans, lorsque votre application de production est encore utilisée, il se peut que npm ne soit pas là. Ou npm peut devenir corrompu; ou les responsables peuvent décider de supprimer la bibliothèque sur laquelle vous comptez depuis leur référentiel; ou la version que vous utilisez peut être supprimée.

Cela peut être atténué avec des gestionnaires de pensions tels que maven, car vous pouvez toujours utiliser votre propre Nexus ou Artifactory local pour gérer un miroir avec les packages que vous utilisez. Pour autant que je sache, un tel système n’existe pas pour npm. Il en va de même pour les gestionnaires de bibliothèques côté client tels que Bower et Jamjs.

Si vous avez engagé les fichiers dans votre propre repository git, vous pouvez les mettre à jour quand bon vous semble et vous bénéficierez du confort des versions répétables et de la certitude que votre application ne sera pas interrompue par des actions tierces.

Vous ne devez pas inclure node_modules dans votre .gitignore (ou plutôt vous devez inclure node_modules dans votre source déployée sur Heroku).

Si node_modules :

• existe alors npm install utilisera ces libs vendues et reconstruira toutes les dépendances binarys avec npm rebuild .
• n’existe pas alors npm install devra récupérer toutes les dépendances qui ajoutent du temps à l’étape de compilation du slug.

Voir la source du buildpack Node.js pour ces étapes exactes

Cependant, l’erreur d’origine semble être une incompatibilité entre les versions de npm et de node . C’est une bonne idée de toujours définir explicitement la section engines de vos packages.json conformément à ce guide pour éviter ces types de situations:

 { "name": "myapp", "version": "0.0.1", "engines": { "node": "0.8.x", "npm": "1.1.x" } } 

Cela assurera la parité dev / prod et réduira la probabilité de telles situations à l’avenir.

J’allais le laisser après ce commentaire: Dois-je vérifier node_modules pour créer une application node.js sur Heroku?

Mais stackoverflow formait un format bizarre. Si vous ne possédez pas de machines identiques et que vous contrôlez node_modules, faites un .gitignore sur les extensions natives. Notre .gitignore ressemble à:

 # Ignore native extensions in the node_modules folder (things changed by npm rebuild) node_modules/**/*.node node_modules/**/*.o node_modules/**/*.a node_modules/**/*.mk node_modules/**/*.gypi node_modules/**/*.target node_modules/**/.deps/ node_modules/**/build/Makefile node_modules/**/**/build/Makefile 

Testez ceci en vérifiant tout d’abord, puis demandez à un autre développeur de faire ce qui suit:

 rm -rf node_modules git checkout -- node_modules npm rebuild git status 

Assurez-vous qu’aucun fichier n’a été modifié.

Je crois que npm install ne doit pas être exécuté dans un environnement de production. Il y a plusieurs choses qui peuvent mal tourner – la panne de npm, le téléchargement de nouvelles dépendances (shrinkwrap semble avoir résolu ce problème) en sont deux.

D’autre part, node_modules ne doit pas être commis sur git. En dehors de leur grande taille, les commits y compris peuvent devenir gênants.

Les meilleures solutions seraient les suivantes: npm install devrait s’exécuter dans un environnement CI similaire à l’environnement de production. Tous les tests seront exécutés et un fichier de version compressé sera créé, qui inclura toutes les dépendances.

J’ai utilisé à la fois le dossier node_modules et le rétrécissement. Les deux solutions ne m’ont pas rendu heureux.

En résumé: node_modules validés ajoute trop de bruit au référentiel.
De plus, shrinkwrap.json n’est pas facile à gérer et rien ne garantit que des projets sous film rétractable seront réalisés dans quelques années.

J’ai trouvé que Mozilla utilisait un repository séparé pour l’un de ses projets https://github.com/mozilla-b2g/gaia-node-modules

Il ne m’a donc pas fallu longtemps pour implémenter cette idée dans un outil CLI de noeud https://github.com/bestander/npm-git-lock

Juste avant chaque construction append
npm-git-lock –repo [[email protected]: votre / dédié / node_modules / git / repository.git]

Il calculera le hash de votre package.json et vérifiera le contenu de node_modules à partir d’un repo distant ou, s’il s’agit d’une première version pour ce package.json, effectuera une npm install propre et transmettra les résultats au référentiel distant.

Ce qui a fonctionné pour moi était d’append explicitement une version de npm à package.json (“npm”: “1.1.x”) et de ne pas archiver node_modules à git. Il peut être plus lent à déployer (car il télécharge les paquets à chaque fois), mais je ne pouvais pas comstackr les paquets quand ils étaient archivés. Heroku était à la recherche de fichiers qui n’existaient que dans ma boîte locale.

Au lieu de vérifier node_modules, créez un fichier package.json pour votre application.

Le fichier package.json spécifie les dépendances de votre application. Heroku peut alors dire à npm d’installer toutes ces dépendances. Le tutoriel auquel vous avez lié contient une section sur les fichiers package.json.

J’utilise cette solution:

1. Créez un référentiel séparé qui contient node_modules . Si vous avez des modules natifs qui doivent être créés pour une plate-forme spécifique, créez un référentiel distinct pour chaque plate-forme.
2. Attachez ces référentiels à votre référentiel de projet avec le git submodule – git submodule :

git submodule add .../your_project_node_modules_windows.git node_modules_windows

git submodule add .../your_project_node_modules_linux_x86_64 node_modules_linux_x86_64

3. Créez un lien entre node_modules spécifique à la node_modules et le répertoire node_modules et ajoutez node_modules à .gitignore .
4. Exécutez npm install .
5. Valider les modifications du référentiel de sous-module.
6. Validez les modifications du référentiel de projet.

Vous pouvez donc facilement basculer entre node_modules sur différentes plates-formes (par exemple, si vous développez sous OS X et que vous le déployez sous Linux).

De https://web.archive.org/web/20150212165006/http://www.futurealoof.com/posts/nodemodules-in-git.html :

Edit: Le lien original était celui-ci mais il est maintenant mort. Merci @Flavio de l’avoir signalé.

Récapituler.

• N’inscrivez que node_modules pour les applications que vous déployez, pas les packages réutilisables que vous gérez.
• La source de toutes les dépendances compilées doit être archivée, et non les cibles de compilation, et $ npm sera reconstruit lors du déploiement.

Ma partie préférée:

Tous ceux qui ont ajouté node_modules à votre gitignore, retirez cette merde, aujourd’hui , c’est un artefact d’une époque que nous sums tous trop heureux de laisser derrière nous. L’ère des modules globaux est morte.

http://nodejs.org/api/modules.html

Le nœud démarre au répertoire parent du module actuel et ajoute /node_modules et tente de charger le module à partir de cet emplacement.

S’il n’y est pas trouvé, il passe au répertoire parent, et ainsi de suite jusqu’à ce que la racine de l’arborescence soit atteinte.

Si vous déployez vos propres modules spécifiques à votre application, vous pouvez les conserver ( et uniquement ceux-ci ) dans les /node_modules votre application. Et déplacez toutes les autres dépendances vers le répertoire parent.

Ce cas d’utilisation assez génial, vous permet de garder les modules que vous avez créés spécifiquement pour votre application avec votre application, et ne pas encombrer votre application avec des dépendances qui peuvent être installées plus tard.