Wie kann ich die Anwendung Node.js mit der tiefen Struktur node_modules unter Windows bereitstellen?

91

Ich bin auf ein merkwürdiges Problem gestoßen - anscheinend haben einige Node.js-Module so tiefe Ordnerhierarchien, dass der Windows-Kopierbefehl (oder der PowerShell-Befehl, Copy-Itemden wir tatsächlich verwenden) den berüchtigten Fehler "Pfad zu lang" trifft, wenn der Pfad über 250 liegt Zeichen lang.

Dies ist beispielsweise eine Ordnerhierarchie, die ein einzelnes Knotenmodul erstellen kann:

node_modules\nodemailer\node_modules\simplesmtp\node_modules\
xoauth2\node_modules\request\node_modules\form-data\node_modules\
combined-stream\node_modules\delayed-stream\...

Es scheint verrückt zu sein, ist aber mit Node-Modulen Realität.

Wir müssen während der Bereitstellung Copy-Paste verwenden (wir verwenden keine "clevere" Zielplattform wie Heroku, bei der eine Git-Bereitstellung eine Option wäre), und dies ist eine schwerwiegende Einschränkung unter Windows.

Gibt es nicht einen npm-Befehl oder etwas, das den node_modulesOrdner komprimiert oder nur das enthält, was zur Laufzeit tatsächlich erforderlich ist? (Knotenmodule enthalten normalerweise testOrdner usw., die wir nicht bereitstellen müssen.) Haben Sie weitere Ideen, wie Sie das umgehen können? Windows nicht zu benutzen ist leider keine Option :)

Borek Bernard
quelle
1
Hat Ihr Projekt ein package.jsonWith- dependenciesSet? Wenn ja, könnten Sie ohne node_modulesund mit npm to installoder updateden Abhängigkeiten kopieren ?
Jonathan Lonowski
4
@JonathanLonowski Unsere Bereitstellungsumgebung unterstützt die Ausführung npm installin der Zielumgebung nicht. Sie erstellt lokal ein "Bereitstellungspaket" (im Grunde eine ZIP- Datei plus einige Metadaten), das dann auf den Zielcomputer hochgeladen, dort extrahiert und fertig ist. Also muss ich node_modulesdirekt einbeziehen.
Borek Bernard

Antworten:

24

npm v3 (kürzlich veröffentlicht) löst dieses Problem, indem die Abhängigkeiten reduziert werden. Lesen Sie die Versionshinweise hier unter https://github.com/npm/npm/releases/tag/v3.0.0 unter flat flatAbschnitt.

Und der letzte Kommentar zu diesem Thema https://github.com/npm/npm/issues/3697

RameshVel
quelle
5
Die Versionshinweise für flat flatsind jetzt auf einer anderen Seite vergraben. Hier ist ein direkter Link: github.com/npm/npm/releases/tag/v3.0.0
John-Philip
Danke @ John-Philip, aktualisierte die Antwort mit dem neuen Link
RameshVel
62

nur um das hinzuzufügen ... eine andere Sache, die mir geholfen hat, war die Auflistung aller installierten Module mit npm ls.

Das gibt Ihnen einen Baum von Modulen und Versionen ... von dort aus ist es ziemlich einfach zu identifizieren, welche Duplikate sind ... npm dedupehat nichts für mich getan. Ich bin mir nicht sicher, ob das ein Fehler ist oder was (Node v 10.16)

Wenn Sie also ein doppeltes Modul identifiziert haben, installieren Sie es mithilfe von im Stammverzeichnis node_module npm install [email protected] --save-dev. Die Version ist wichtig.

Danach habe ich mein Verzeichnis node_modules gelöscht und ein neues erstellt npm install.

Kurzfassung

  1. npm ls um eine Liste aller installierten Module zu erhalten.
  2. Durchsuchen Sie diese Module und identifizieren Sie doppelte Module ( Version ist wichtig )
  3. npm install module@version --save-dev um diese Module im Stammverzeichnis node_modules zu installieren und package.json zu aktualisieren.
  4. rmdir node_modules um das Verzeichnis node_modules zu löschen.
  5. npm install um eine neue Kopie Ihrer Abhängigkeiten abzurufen.

Sobald ich das tat, war alles viel sauberer.

Ich empfehle außerdem, Ihre package.json-Datei zu kommentieren, um zu zeigen, welche heruntergefahren wurden, um den node_modules-Baum zu reduzieren.

Ben Lesh
quelle
Das hat bei mir super funktioniert. Danke dir! Verzeihen Sie meine Unwissenheit, aber warum werden Module nicht immer auf der obersten Ebene installiert?
Caleb
2
@Caleb wahrscheinlich, weil verschiedene Module auf verschiedenen Versionen desselben Moduls basieren, oder weil es einfacher ist, einfach alles zu bekommen, was benötigt wird, und es dann herunterzurechnen ... Ich weiß nicht.
Ben Lesh
7
Trotzdem danke für den Tipp. Ich habe gerade ungefähr 1700 doppelte Dateien aus unserem Projekt weggeblasen. Das Löschen von Dingen ist mein Lieblingsteil als Entwickler! Für alle, die sich mit dem Hinzufügen von Kommentaren zu package.json befassen, ist hier Ihre Antwort: stackoverflow.com/questions/14221579/…
Caleb
github.com/joyent/node/issues/6960 Node Guy sagt, dass Windows ein erstklassiger Bürger ist. Sie sagten. Aber sie haben das Problem geschlossen und nichts behoben. Glückliche Windows-Benutzer.
vee
38

Ich denke nicht, dass es angesichts Ihrer Einschränkungen eine großartige Lösung gibt, aber hier sind einige Dinge, die helfen können.

  • Versuchen Sie npm dedupe, Ihre Verzeichnishierarchie zu optimieren, um einige Pfade zu verkürzen
  • Verwenden Sie npm install --productiondiese Option, um ohne die Entwicklungstools zu installieren
  • Nehmen Sie einige dieser tief verschachtelten Abhängigkeiten (gerade genug, um das Problem zu vermeiden, schlage ich vor) und verschieben Sie sie in das Verzeichnis node_modules der obersten Ebene. Behalten Sie sie im Auge, damit Sie wissen, welche Abhängigkeiten Ihre wahren sind und welche Problemumgehungen für dieses Problem gelten.
  • ODER Verschieben Sie einige dieser tiefen Abhängigkeiten in das höchste node_modulesVerzeichnis your_project/node_modules/pkg_with_deep_deps, in dem sie genügend kurze Pfade haben, aber trotzdem funktionieren. Das wäre also so your_project/node_modules/pkg_with_deep_deps/node_modules.
    • Ich denke, requiresollte in der Lage sein, diese zur Laufzeit richtig zu finden. Sie müssen nur klar dokumentieren, was Sie manuell geändert haben, warum Sie es getan haben, und Ihre eigenen wahren Abhängigkeiten genau darstellenpackage.json

Hier ist eine Diskussion zum Thema Github , in der dieses Problem ausführlich behandelt wird.

Peter Lyons
quelle
Vielen Dank für den Hinweis dedupe(wusste überhaupt nichts davon) und --production( npm install -hzeigte diese Option nicht)! Die Verwendung eines ZIP-Archivs ist leider keine Option, siehe Kommentar oben.
Borek Bernard
9
npm dedupe reduziert die "gemeinsamen" Module nur auf den niedrigsten gemeinsamen Ort in der Hierarchie. Nicht gut genug. Eine geeignete Lösung würde es ermöglichen, die gesamte Hierarchie zu "erzwingen" und möglicherweise die Test- / Dokumentverzeichnisse zu ignorieren. Eine Alternative wäre, dass der Knoten das Lesen von Modulen direkt aus einer TAR-Datei unterstützt.
MMind
3
Einverstanden wäre eine Art "binäre" Verteilung von Paketen (ZIP, Tarball, was auch immer) sehr nützlich.
Borek Bernard
11

Ich habe ein Knotenmodul namens "npm-flatten" geschrieben, das Ihre Abhängigkeiten für Sie hier abflacht: https://www.npmjs.org/package/npm-flatten

Wenn Sie nach einer Verteilung suchen, habe ich auch ein NuGet-Paket geschrieben, das eine vollständige node.js-Umgebung in Ihr .NET-Projekt integriert: http://www.nuget.org/packages/NodeEnv/

Feedback wäre willkommen.

user3602171
quelle
Das hat bei uns funktioniert. Wir hatten noch bessere Ergebnisse, als wir zuerst nmp dedup ausgeführt haben.
Shaun Rowan
1

Etwas, das mir geholfen hat, war, ein lokales Laufwerk meinem Ordner Node.js zuzuordnen:

Nettonutzung n: \ Computername \ c $ \ Benutzer \ mein Name \ Dokumente \ node.js / persistent: ja

Vorher: c: \ Benutzer \ mein Name \ Dokumente \ node.js \ Projektname (45 Zeichen) Nachher: ​​n: \ Projektname (14 Zeichen, das sind 31 Zeichen weniger)

In vielen Fällen konnten dadurch einige Module installiert werden.

Ich werde sagen, dass ich dieses Problem heute gerade wieder entdeckt habe, als ich versucht habe, meinen gesamten Code auf einem USB-Laufwerk zu sichern.

"C: \ Benutzer \ mein Name \ Dokumente \ Node.js \ Angular-Phonecat \ Knotenmodule \ Karma \ Knotenmodule \ Chokidar \ Knotenmodule \ Anymatch \ Knotenmodule \ Mikromatch \ Knotenmodule \ Regex-Cache \ Knotenmodule \ Benchmarked \ Knotenmodule \ Dateireader \ node_modules \ verlängern-flach \ Benchmark \ Geräte ist zu lang. "

Selbst wenn ich versuchte, sie mit dem Laufwerksbuchstaben N: zu sichern, schlug dies in einigen Fällen aufgrund von Pfadlängen fehl, aber es reichte gerade aus, um den obigen Fehler zu beheben.

Michael Blankenship
quelle
1

1) Während der Release-Erstellung können Sie verhindern, dass Visual Studio diese Dateien / Ordner scannt, indem Sie die Ordnereigenschaften als versteckten Ordner festlegen (setzen Sie ihn NUR auf node_modules). Referenz: http://issues.umbraco.org/issue/U4-6219#comment=67-19103

2) Sie können Dateien oder Ordner ausschließen, die während des Packens veröffentlicht werden, indem Sie den folgenden XML-Knoten in die CsProject-Datei aufnehmen.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  ...
  <OutputPath>bin\</OutputPath>
   <NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
  <ExcludeFilesFromDeployment>File1.aspx;File2.aspx</ExcludeFilesFromDeployment>
  <ExcludeFoldersFromDeployment>Folder1;Folder2</ExcludeFoldersFromDeployment>
</PropertyGroup>
David Chelliah
quelle
1

Ich habe eine Lösung aus den Microsoft Node.js-Richtlinien gefunden .

  • Beginnen Sie auf einem kurzen Weg (zB c: \ src)
  • > npm install -g rimraf Dateien löschen, die überschreiten max_path
  • > npm dedupe Verschiebt doppelte Pakete auf die oberste Ebene
  • > npm install -g flatten-packages Verschiebt alle Pakete auf die oberste Ebene, kann jedoch zu Versionsproblemen führen
  • Upgrade auf npm@3welche Versuche, die node_modulesOrdner-Hierarchie maximal flach zu machen.
    • Wird mit Node v5 geliefert
    • Oder… > npm install –g npm-windows-upgrade
zangw
quelle
0

Dies ist keine richtige Lösung, sondern eine Lösung, wenn Sie es eilig haben. Sie können jedoch 7-Zip verwenden, um Ihren Ordner zu komprimieren, die komprimierte Datei zu verschieben und sie ohne Probleme zu entpacken.

Wir haben diese Lösung verwendet, um eine Node.js-Anwendung bereitzustellen, bei der eine saubere npm-Installation nicht möglich war.

Jason
quelle
Ja. Dies ist, was ich jedes Mal mache, wenn ich Mungo installieren muss. Es enthält nativen Code und ich habe mehrere / neuere Versionen von Visual Studio = fail. Ich könnte einfach VS öffnen, jede fehlgeschlagene SLN-Datei einspielen und neu erstellen lassen. Es ist jedoch einfacher, bei Bedarf XCOPY über meine gesamte Ordnergruppe node_modules \ mongoose zu erstellen (natürlich Versionen ansehen).
Michael Blankenship