Sollte ich node_modules einchecken, um git zu erstellen, wenn ich eine node.js-App auf Heroku erstelle?

Ich habe die grundlegenden Anweisungen für den Einstieg in 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 Einstiegsanwendung korrekt ausgeführt.

Als ich dem fortgeschritteneren Beispiel folgte:

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

Es hat mich angewiesen, node_modules zu .gitignore hinzuzufügen. Also habe ich node_modules aus git entfernt, es zu .gitignore hinzugefügt und dann erneut bereitgestellt. Diesmal ist die Bereitstellung wie folgt fehlgeschlagen:

-----> 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: node@0.4 || 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: node@0.4 || 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 zurückgesetzt, node_module wieder zum Git-Repository hinzugefügt und es aus .gitignore entfernt. Selbst nach dem Zurücksetzen wird beim Bereitstellen immer noch dieselbe Fehlermeldung angezeigt, aber jetzt wird die Anwendung wieder ordnungsgemäß ausgeführt. Wenn Sie "heroku ps" ausführen, wird mir mitgeteilt, dass die Anwendung ausgeführt wird.

Meine Frage ist also, wie man das richtig macht. Node_modules einschließen oder nicht? Und warum wird beim Rollback immer noch die Fehlermeldung angezeigt? Ich vermute, dass sich das Git-Repository auf der Heroku-Seite in einem schlechten Zustand befindet?

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 100% ige Sicherheit zu haben, eine Bereitstellung oder einen Build reproduzieren zu können, sollten Sie Ihre Abhängigkeiten in der Quellcodeverwaltung überprüfen oder einen anderen Mechanismus verfolgen, der dies überprüfen kann 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, den node_modulesOrdner festzuschreiben.

Normalerweise nein. Erlauben Sie npm, Abhängigkeiten für Ihre Pakete aufzulösen.

Für von Ihnen bereitgestellte Pakete wie 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 klar:

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

und für einige gute Gründe lesen Sie den Beitrag von Mikeal Rogers dazu .

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

Meine größte Sorge mit nicht überprüft node_modulesin git ist , dass 10 Jahre auf der Straße, wenn Ihre Produktion Anwendung noch in Gebrauch ist, npm nicht um kann. Oder npm könnte beschädigt werden; oder die Betreuer entscheiden sich möglicherweise dafür, die Bibliothek, auf die Sie sich verlassen, aus ihrem Repository zu entfernen. oder die von Ihnen verwendete Version wird möglicherweise abgeschnitten.

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 verwalten. 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-Repo festgeschrieben haben, können Sie sie jederzeit aktualisieren. Sie haben den Komfort wiederholbarer Builds und das Wissen, dass Ihre App aufgrund von Aktionen von Drittanbietern nicht beschädigt wird.

Sie sollten nicht enthalten node_modules in Ihrem .gitignore(oder besser gesagt Sie sollten enthalten node_modules in Ihrer Quelle zu Heroku eingesetzt).

Wenn node_modules:

• Existiert dann npm installwerden diese Vendored Libs verwendet und alle binären Abhängigkeiten mit neu erstellt npm rebuild.
• existiert nicht, dann npm installmüssen alle Abhängigkeiten selbst abgerufen werden, was dem Slug-Kompilierungsschritt Zeit hinzufügt.

Die genauen Schritte finden Sie in der Buildpack-Quelle von Node.js.

Der ursprüngliche Fehler scheint jedoch eine Inkompatibilität zwischen den Versionen von npmund zu sein node. Es ist eine gute Idee, den enginesAbschnitt Ihres Handbuchs immer explizit packages.jsongemäß diesem Handbuch festzulegen , um folgende Situationen zu vermeiden:

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

Dies wird die Entwicklungs- / Produktparität sicherstellen und die Wahrscheinlichkeit solcher Situationen in Zukunft verringern.

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

Aber Stackoverflow formatierte es seltsam. Wenn Sie keine identischen Computer haben und node_modules einchecken, führen Sie einen Gitignore für die nativen Erweiterungen durch. Unser .gitignore sieht aus wie:

# 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 einen anderen Entwickler die folgenden Schritte ausführen lassen:

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

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

Ich glaube, das npm installsollte nicht in einer Produktionsumgebung laufen. Es gibt mehrere Dinge, die schief gehen können - npm-Ausfall, Download neuerer Abhängigkeiten (Shrinkwrap scheint dies gelöst zu haben) sind zwei davon.

Auf der anderen Seite node_modulessollte nicht auf Git begangen werden. Abgesehen von ihrer Größe können Commits, einschließlich dieser, ablenken.

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

Ich habe sowohl das Festschreiben des Ordners node_modules als auch das Schrumpfen verwendet. Beide Lösungen haben mich nicht glücklich gemacht.

Kurz gesagt: Festgeschriebene Knotenmodule fügen 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 fand heraus, dass Mozilla ein separates Repository für eines ihrer Projekte verwendete: https://github.com/mozilla-b2g/gaia-node-modules

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

Fügen Sie kurz vor jedem Build npm-git-lock hinzu --repo [git@bitbucket.org: Ihr / dediziertes / Knotenmodul / git / repository.git]

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

Was für mich funktionierte, war das explizite Hinzufügen einer npm-Version zu package.json ("npm": "1.1.x") und das NICHT-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 auf meiner lokalen Box vorhanden waren.

Erstellen Sie anstelle von node_modules eine package.json-Datei für Ihre App.

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 zu package.json-Dateien.

Ich benutze diese Lösung:

1. Erstellen Sie ein separates Repository, das enthält 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. Fügen Sie diese Repositorys Ihrem Projekt-Repository hinzu mit 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. Link Erstellen von plattformspezifischen node_moduleszu node_modulesVerzeichnis und fügen Sie node_moduleszu .gitignore.
4. Ausführen npm install.
5. Änderungen am Submodul-Repository festschreiben.
6. Übernehmen Sie die Änderungen Ihres Projekt-Repositorys.

So können Sie problemlos zwischen node_modulesverschiedenen Plattformen wechseln (z. B. wenn Sie unter OS X entwickeln und unter Linux bereitstellen).

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 noch einmal zusammenzufassen.

• Checken Sie nur node_modules für von Ihnen bereitgestellte Anwendungen ein, nicht 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 zurücklassen. Die Ära der globalen Module ist tot.

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

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

Wenn es dort nicht gefunden wird, wird es in das übergeordnete Verzeichnis usw. verschoben , bis das Stammverzeichnis des Baums erreicht ist.

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

In diesem Anwendungsfall, der ziemlich beeindruckend ist, können Sie Module, die Sie speziell für Ihre App erstellt haben, gut mit Ihrer App kombinieren und Ihre App nicht mit Abhängigkeiten überladen, die später installiert werden können.

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 der package.json haben, können Sie ihn nicht mehr erhalten. Wenn ein Paket weniger als 24 Stunden alt ist, können Sie es problemlos 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 durch das Entfernen dieser Version Ihres Pakets andere Installationen beschädigt werden. Wenn ja, werden wir es nicht entfernen.

Weiterlesen

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 Ihr 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 um function2(x)und machen einen Fehler ... Sie ändern die Version ihres Pakets von 1.0.1auf 1.1.0. Dies ist ein Problem, da Sie npm installbeim nächsten Aufruf die Version akzeptieren, 1.1.0da Sie tilde ( "studpid-package": "~1.0.1") verwendet haben.

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

Das Verschieben des gesamten Ordners node_modules (häufig mehr als 100 MB) in Ihr Repository kostet Speicherplatz. 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 Sie Geld, wenn etwas ausfällt.

• Sie vertrauen der npm-Registrierung nicht. npm ist zentralisiert und könnte theoretisch heruntergefahren werden.

Sie brauchen nicht , wenn die node_modules Ordner in 99,9% der Fälle zu veröffentlichen:

• Sie entwickeln eine Software nur für sich.

• Sie haben etwas programmiert und möchten das Ergebnis nur auf GitHub veröffentlichen, weil 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 .gitignoreDatei und fügen Sie die Zeile hinzu node_modules.