Verwandte: single node_modules folder for multiple projectsHaben Sie project_name/node_modules als Symlink?
Wenn npm install -g alles ist nicht zu empfehlen, und ich will nicht einzelne Module verbinden, ich möglicherweise Symlink kann <some project>/node_modules auf ein gemeinsames Verzeichnis von mehreren Projekten gemeinsam genutzt werden?
Knoten kann die Symlinks perfekt in Ordnung. Wie Sie dies erreichen können, hängt von einigen Ihrer Ziele ab. Das wichtigste ist: Welche Erfahrung möchten Sie für andere Entwickler haben, die Ihr (e) Projekt (e) von der Versionskontrolle herunterladen?
Beim Entwerfen dieser Erfahrung ist es sehr hilfreich, über den Algorithmus zum Laden von Knotenmodulen zu lesen, um einen Einblick in die Möglichkeiten zu erhalten.
Im Allgemeinen ist meine Empfehlung nicht mit duplizierten Abhängigkeiten zwischen den Projekten zu befassen. "Reparieren" ist die Wartungskosten nicht wert, einschließlich des Abhängigkeits-Gridlocks (widersprüchliche Anforderungen der Teilprojekte), und in einigen Fällen müssen benutzerdefinierte Werkzeuge verwendet werden, um Ihre benutzerdefinierte Struktur zu berücksichtigen.
Mit dieser Warnung aus dem Weg, wie machen wir es? Der einfachste Weg besteht darin, ein Superprojekt zu erstellen, das verschiedene Teilprojekte einkapselt. Die Teilprojekte erben die Abhängigkeiten des Superprojekts effektiv.
superproject/
|-- node_modules/
| +-- socket.io/
|-- package.json
|-- subprojectA/
| |-- node_modules/
| | +-- browserify/
| |-- package.json
| +-- app/
| +-- client.js
+-- subprojectB/
|-- node_modules/
| +-- express/
|-- package.json
+-- lib/
+-- server.js
arbeitet Diese Struktur, wie man erwarten könnte, um die Dateien innerhalb der Teilprojekte können ihre eigenen Module und alle diejenigen in superproject/node_modules, aber sie werden nicht leicht require() die Module innerhalb ihrer Geschwister Teilprojekte (es ist immer noch möglich, require() tun Sie dies über explizite Pfade). Mit anderen Worten, client.js kann require() browserify und socket.io ohne einen Pfad, aber es müsste einen Pfad zu require() Express verwenden. Ein wichtiger Aspekt dabei ist, dass npm eine Suche nach einem package.json ausführt und Module in einem node_modules Verzeichnis als ein Geschwister zu dieser Datei bei der Installation usw. behandelt. Dies bedeutet, dass Ihr aktuelles Arbeitsverzeichnis muss superproject sein, um Module darin zu installieren, es sei denn, Ihr Unterprojekt hat keine package.json Datei.
Die "doppelten Abhängigkeiten" sind ein großes Problem, da die Dateien selbst bei sehr kleinen Projekten sehr viel Platz beanspruchen und bei der Einrichtung neuer (meist) gleicher Projekte zu einer indirekten Verschwendung von Bandbreite führen Abhängigkeiten. – prusswan
Ich kann auf diese Wünsche beziehen. Aber ich denke, Sie werden feststellen, dass die enge Kopplung verschiedener Projekte auf diese Weise eine andere Art von Belastung erzeugt. Eine, in der Sie eine Abhängigkeit nicht aktualisieren können, da Projekt x ein bestimmtes Verhalten benötigt. Aber Sie wollen/müssen es wirklich aktualisieren, weil Projekt y es anders verwendet und etwas neues benötigt. In den alten Tagen waren alle npm-Module global, diese Praxis wurde gestoppt, weil die Community erkannte, dass es sich nicht lohnt. https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/ Alles, was gesagt wird, gibt es noch Möglichkeiten, pseudo-globale Module zu tun. –
Das Superprojekt ist eine brillante Lösung! Danke vielmals. In meinem Fall arbeite ich an mehreren Laravel-PHP-Projekten, die Knoten für reine Entwicklungsaufgaben (gulp) verwenden.Gulp und require() funktionieren nur, wenn sie lokal installiert werden, aber das Duplizieren von 200MB node_modules für jedes 5MB PHP-Projekt ist völlig unvernünftig, zumal ich selbst keine Knoten-Entwicklung mache. Das Superprojekt ist die einzige vernünftige Lösung, die ich gefunden habe: Ich kann einen Laravel-5.2-Ordner mit einer einzigen Kopie der von 5.2 benötigten Tools haben, neben allen 5.2-Projekten und so weiter. Brillant! – Tobia