wake-up-neo.net

Sollte ich node_modules einchecken, um beim Erstellen einer node.js-App auf Heroku zu git?

Ich habe die grundlegenden Anweisungen für die ersten Schritte mit node.js auf Heroku hier befolgt:

https://devcenter.heroku.com/categories/nodejs

Diese Anweisung fordert Sie nicht auf, ein .gitignore-Knotenmodul zu erstellen, und impliziert daher, dass Knotenmodule in git eingecheckt werden sollten. Wenn ich node_modules in git einbinde, wurde meine Anwendung "Erste Schritte" ordnungsgemäß ausgeführt.

Als ich dem fortgeschritteneren Beispiel folgte:

https://devcenter.heroku.com/articles/realtime-polyglot-app-node-Ruby-mongodb-socketiohttps://github.com/mongolab/tractorpush-server (Quelle)

Es wies mich an, node_modules zu .gitignore hinzuzufügen. Also entfernte ich node_modules aus git, fügte es zu .gitignore hinzu und stellte es erneut bereit. Diesmal schlug der Einsatz folgendermaßen fehl:

-----> Heroku receiving Push
-----> Node.js app detected
-----> Resolving engine versions
       Using Node.js version: 0.8.2
       Using npm version: 1.0.106
-----> Fetching Node.js binaries
-----> Vendoring node into slug
-----> Installing dependencies with npm
       Error: npm doesn't work with node v0.8.2
       Required: [email protected] || 0.5 || 0.6
           at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
           at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
           at Module._compile (module.js:449:26)
           at Object.Module._extensions..js (module.js:467:10)
           at Module.load (module.js:356:32)
           at Function.Module._load (module.js:312:12)
           at Module.require (module.js:362:17)
           at require (module.js:378:17)
           at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
           at Module._compile (module.js:449:26)
       Error: npm doesn't work with node v0.8.2
       Required: [email protected] || 0.5 || 0.6
           at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
           at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
           at Module._compile (module.js:449:26)
           at Object.Module._extensions..js (module.js:467:10)
           at Module.load (module.js:356:32)
           at Function.Module._load (module.js:312:12)
           at Module.require (module.js:362:17)
           at require (module.js:378:17)
           at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
           at Module._compile (module.js:449:26)
       Dependencies installed
-----> Discovering process types
       Procfile declares types -> mongod, redis, web
-----> Compiled slug size is 5.0MB
-----> Launching... done, v9

Das Ausführen von "heroku ps" bestätigt den Absturz. Ok, kein Problem, also habe ich die Änderung rückgängig gemacht, node_module wieder zum Git-Repository hinzugefügt und es aus .gitignore entfernt. Ich erhalte jedoch auch nach dem Zurücksetzen immer noch die gleiche Fehlermeldung bei der Bereitstellung, aber jetzt wird die Anwendung wieder korrekt ausgeführt. Das Ausführen von "heroku ps" teilt mir mit, dass die Anwendung ausgeführt wird.

Meine Frage ist also, wie man das richtig macht. Node_modules einbinden oder nicht? Und warum erhalte ich beim Rollback immer noch die Fehlermeldung? Meine Vermutung ist, dass sich das Git-Repository auf der Heroku-Seite in einem schlechten Zustand befindet?

359
Jason Griffin

Zweites Update

Die FAQ ist nicht mehr verfügbar.

Aus der Dokumentation von shrinkwrap :

Wenn Sie die in einem Paket enthaltenen spezifischen Bytes sperren möchten, um beispielsweise zu 100% sicher zu sein, dass eine Bereitstellung oder ein Build reproduziert werden kann, sollten Sie Ihre Abhängigkeiten in der Quellcodeverwaltung überprüfen oder einen anderen Mechanismus anwenden, der dies überprüft Inhalte statt Versionen.

Shannon und Steven haben dies bereits erwähnt, aber ich denke, es sollte Teil der akzeptierten Antwort sein.


Aktualisieren

Die für die folgende Empfehlung aufgeführte Quelle wurde aktualisiert . Sie empfehlen nicht mehr die node_modules Ordner festgeschrieben werden.

Normalerweise nein. Erlaube npm, Abhängigkeiten für deine Pakete aufzulösen.

Für Pakete, die Sie bereitstellen, z. B. Websites und Apps, sollten Sie npm shrinkwrap verwenden, um Ihren vollständigen Abhängigkeitsbaum zu sperren:

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


Ursprünglicher Beitrag

Als Referenz beantwortet npm FAQ Ihre Frage eindeutig:

Überprüfen Sie node_modules in git auf Dinge, die Sie bereitstellen, z. B. Websites und Apps. Überprüfen Sie node_modules in git nicht auf Bibliotheken und Module, die wiederverwendet werden sollen. Verwenden Sie npm, um Abhängigkeiten in Ihrer Entwicklungsumgebung zu verwalten, nicht jedoch in Ihren Bereitstellungsskripten.

und für einige gute Gründe lesen Sie Mikeal Rogers 'Beitrag daz .


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

390
Kostia

Meine größte Sorge bei nicht dem Einchecken von node_modules In git ist, dass npm nach 10 Jahren, wenn Ihre Produktionsanwendung noch verwendet wird, möglicherweise nicht verfügbar ist. Oder npm könnte beschädigt werden. oder die Betreuer entscheiden sich möglicherweise, die Bibliothek, auf die Sie sich verlassen, aus ihrem Repository zu entfernen. oder die Version, die Sie verwenden, wird möglicherweise entfernt.

Dies kann mit Repo-Managern wie maven gemildert werden, da Sie immer Ihren eigenen lokalen Nexus oder Artifactory verwenden können, um einen Spiegel mit den von Ihnen verwendeten Paketen zu pflegen. Soweit ich weiß, gibt es ein solches System für npm nicht. Gleiches gilt für clientseitige Bibliotheksverwalter wie Bower und Jamjs.

Wenn Sie die Dateien für Ihr eigenes Git-Repository festgeschrieben haben, können Sie sie aktualisieren, wenn Sie möchten, und Sie haben den Komfort wiederholbarer Builds und das Wissen, dass Ihre App aufgrund von Aktionen von Drittanbietern nicht beschädigt wird.

158
Jonathan

Sie sollten nicht einschließennode_modules In Ihrem .gitignore (Oder vielmehr Sie sollten einschließennode_modules in Ihrer Quelle bereitgestellt für Heroku).

Wenn node_modules:

  • existiert , dann verwendet npm install diese verkauften Bibliotheken und erstellt alle binären Abhängigkeiten mit npm rebuild neu.
  • existiert nicht , dann muss npm install alle Abhängigkeiten selbst abrufen, was dem Slug-Kompilierungsschritt Zeit hinzufügt.

In der Buildpack-Quelle für Node.js finden Sie genau diese Schritte

Der ursprüngliche Fehler scheint jedoch eine Inkompatibilität zwischen den Versionen von npm und node zu sein. Es ist eine gute Idee, den Abschnitt engines in Ihrem packages.json Immer explizit entsprechend dieser Anleitung festzulegen, um solche Situationen zu vermeiden:

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

Dadurch wird dev/prod parity sichergestellt und die Wahrscheinlichkeit solcher Situationen in Zukunft verringert.

67
Ryan Daigle

Ich wollte dies nach diesem Kommentar verlassen: Sollte ich node_modules einchecken, um beim Erstellen einer node.js-App auf Heroku zu git?

Aber Stackoverflow formatierte es seltsam. Wenn Sie nicht über identische Computer verfügen und node_modules einchecken, erstellen Sie einen .gitignore für die nativen Erweiterungen. Unser .gitignore sieht so aus:

# 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

Testen Sie dies, indem Sie zuerst alles einchecken und dann von einem anderen Entwickler Folgendes ausführen lassen:

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

Stellen Sie sicher, dass keine Dateien geändert wurden.

22
ibash

Ich glaube das npm install sollte nicht in einer Produktionsumgebung ausgeführt werden. Es gibt mehrere Dinge, die schief gehen können - npm Ausfall, Download neuerer Abhängigkeiten (Shrinkwrap scheint dies zu lösen) sind zwei davon.

Auf der anderen Seite, node_modules sollte nicht auf git festgelegt werden. Abgesehen von ihrer Größe können Commits, zu denen sie gehören, ablenken.

Die besten Lösungen wären: npm install sollte in einer CI-Umgebung ausgeführt werden, die der Produktionsumgebung ähnelt. Alle Tests werden ausgeführt und eine komprimierte Release-Datei erstellt, die alle Abhängigkeiten enthält.

10
user2468170

Ich habe sowohl den Ordner node_modules als auch das Shrink-Wrapping verwendet. Beide Lösungen haben mich nicht glücklich gemacht.

Kurz gesagt: Committed Node_modules fügt dem Repository zu viel Rauschen hinzu.
Und shrinkwrap.json ist nicht einfach zu verwalten, und es gibt keine Garantie dafür, dass ein in Schrumpffolie verpacktes Projekt in einigen Jahren erstellt wird.

Ich habe festgestellt, dass Mozilla für eines seiner Projekte ein separates Repository verwendet https://github.com/mozilla-b2g/gaia-node-modules

Daher habe ich nicht lange gebraucht, um diese Idee in einem Knoten-CLI-Tool zu implementieren https://github.com/bestander/npm-git-lock

Kurz vor jedem Build hinzufügen
npm-git-lock --repo [[email protected]: your/dedicated/node_modules/git/repository.git]

Es berechnet den Hash Ihres package.json und checkt entweder den Inhalt von node_modules aus einem Remote-Repo aus oder führt, wenn es sich um einen ersten Build für dieses package.json handelt, eine Bereinigung durch npm install und die Ergebnisse an das Remote-Repo senden.

8
bestander

Was für mich funktionierte, war das explizite Hinzufügen einer npm-Version zu package.json ("npm": "1.1.x") und NICHT das Einchecken von node_modules in git. Die Bereitstellung ist möglicherweise langsamer (da die Pakete jedes Mal heruntergeladen werden), aber ich konnte die Pakete beim Einchecken nicht kompilieren. Heroku suchte nach Dateien, die nur in meiner lokalen Box vorhanden waren.

5
Jason Griffin

Erstellen Sie eine package.json-Datei für Ihre App, anstatt node_modules einzuchecken.

Die Datei package.json gibt die Abhängigkeiten Ihrer Anwendung an. Heroku kann dann npm anweisen, alle diese Abhängigkeiten zu installieren. Das Tutorial, mit dem Sie verlinkt haben, enthält einen Abschnitt über package.json-Dateien.

3
matzahboy

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

Bearbeiten: Der ursprüngliche Link war dieser aber er ist jetzt tot. Vielen Dank an @Flavio für den Hinweis.

Um es zusammenzufassen.

  • Checken Sie node_modules nur für Anwendungen ein, die Sie bereitstellen, nicht für wiederverwendbare Pakete, die Sie verwalten.
  • Bei kompilierten Abhängigkeiten sollte die Quelle eingecheckt sein, nicht die Kompilierungsziele, und $ npm sollte bei der Bereitstellung neu erstellt werden.

Mein Lieblingsabschnitt:

Alle Leute, die node_modules zu Ihrem Gitignore hinzugefügt haben, , entfernen diese Scheiße. Heute ist es ein Artefakt einer Ära, die wir nur allzu gerne hinter uns lassen. Die Ära der globalen Module ist vorbei.

3

Ich benutze diese Lösung:

  1. Erstellen Sie ein separates Repository mit node_modules. Wenn Sie native Module haben, die für eine bestimmte Plattform erstellt werden sollen, erstellen Sie für jede Plattform ein separates Repository.
  2. Hängen Sie diese Repositorys mit git submodule An Ihr Projekt-Repository an:

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

  1. Erstellen Sie einen Link vom plattformspezifischen Verzeichnis node_modules Zum Verzeichnis node_modules Und fügen Sie node_modules Zu .gitignore Hinzu.
  2. Führen Sie npm install Aus.
  3. Änderungen am Submodul-Repository festschreiben.
  4. Übernehmen Sie die Änderungen an Ihrem Projekt-Repository.

Auf diese Weise können Sie auf verschiedenen Plattformen problemlos zwischen node_modules Wechseln (z. B. wenn Sie unter OS X entwickeln und unter Linux bereitstellen).

3
mixel

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

Der Knoten [...] beginnt im übergeordneten Verzeichnis des aktuellen Moduls und fügt /node_modules hinzu und versucht, das Modul von diesem Speicherort aus zu laden.

Wird es dort nicht gefunden , wird es in das übergeordnete Verzeichnis verschoben , bis die Wurzel des Baums erreicht ist.

Wenn Sie Ihre eigenen Module für Ihre App rollen, können Sie diese ( und nur die) im /node_modules Ihrer App behalten. Verschieben Sie alle anderen Abhängigkeiten in das übergeordnete Verzeichnis.

Dieser Anwendungsfall ist ziemlich beeindruckend. Mit ihm können Sie Module, die Sie speziell für Ihre App erstellt haben, gut mit Ihrer App kombinieren und Ihre App wird nicht mit Abhängigkeiten überfrachtet, die später installiert werden können.

2
laggingreflex

Szenario 1:

Ein Szenario: Sie verwenden ein Paket, das aus npm entfernt wird. Wenn Sie alle Module im Ordner node_modules haben, ist dies für Sie kein Problem. Wenn Sie nur den Paketnamen in package.json haben, können Sie ihn nicht mehr abrufen. Wenn ein Paket weniger als 24 Stunden alt ist, können Sie es einfach aus npm entfernen. Wenn es älter als 24 Stunden ist, müssen Sie sie kontaktieren. Aber:

Wenn Sie sich an den Support wenden, wird geprüft, ob das Entfernen dieser Version Ihres Pakets andere Installationen beeinträchtigen würde. Wenn ja, werden wir es nicht entfernen.

lesen Sie mehr

Die Chancen dafür sind also gering, aber es gibt Szenario 2 ...


Szenario 2:

Ein anderes Szenario, in dem dies der Fall ist: Sie entwickeln eine Unternehmensversion Ihrer Software oder eine sehr wichtige Software und schreiben in Ihre package.json:

"dependencies": {
    "studpid-package": "~1.0.1"
}

Sie verwenden die Methode function1(x) dieses Pakets.

Jetzt benennen die Entwickler von studpid-package die Methode function1(x) in function2(x) um und machen einen Fehler ... Sie ändern die Version ihres Pakets von 1.0.1 In 1.1.0. Dies ist ein Problem, da Sie beim nächsten Aufruf von npm install Die Version 1.1.0 Akzeptieren, weil Sie die Tilde ("studpid-package": "~1.0.1") Verwendet haben.

Das Aufrufen von function1(x) kann jetzt Fehler und Probleme verursachen.


Wenn Sie den gesamten Ordner "node_modules" (häufig mehr als 100 MB) in Ihr Repository verschieben, werden Sie Speicherplatz kosten. Ein paar KB (nur package.json) im Vergleich zu Hunderten von MB (package.json & node_modules) ... Denken Sie darüber nach.

Sie könnten es tun/sollten darüber nachdenken wenn:

  • die Software ist sehr wichtig.

  • es kostet Geld, wenn etwas ausfällt.

  • du vertraust der npm Registry nicht. npm ist zentralisiert und könnte theoretisch heruntergefahren werden.

Sie müssen nicht, um den node_modules-Ordner in 99,9% der Fälle zu veröffentlichen, wenn:

  • sie entwickeln eine Software nur für sich.

  • sie haben etwas programmiert und möchten das Ergebnis nur auf GitHub veröffentlichen, da sich möglicherweise jemand anderes dafür interessiert.


Wenn Sie nicht möchten, dass sich die node_modules in Ihrem Repository befinden, erstellen Sie einfach eine .gitignore - Datei und fügen Sie die Zeile node_modules Hinzu.

1
ndsvw