Zugang aus einem anderen Ordner node_modules

Vor kurzem begann die Zusammenarbeit mit Gulp und ich kann nicht herausfinden, ist es wirklich notwendig, eine Kopie der node_modules direkt im Ordner mit dem aktuellen Projekt?
E. g. Ich habe diese Struktur:

mysite

└─builder

      └──node_modules

└─Arbeit

└─work2

Wie kann ich den Zugriff node_modules im Ordner 'generator' aus dem Ordner 'Arbeit' oder 'work2', ohne Sie zu kopieren? Es ist ziemlich groß, über 100 MB, und mir scheint, es hat keinen Sinn, die haben eine Kopie davon für jedes neue Projekt.

Habe ich versucht, diese Linie export NODE_PATH='D:\OpenServer\domains\mysite\build' im Datei-Paket.json und versuchte dann den Befehl gulp aber es antwortete
[10:24:27] Local gulp not found in d:\OpenServer\domains\mysite\work
[10:24:27] Try running: npm install gulp

  • Fand eine partielle Lösung bei der Umsetzung-Ordner 'Arbeitsplatz', 'work2'... im Ordner "builder", wie node_modules erkannt werden kann, in den übergeordneten Ordner.
  • warum setzen Sie sich node_modules innen-builder?, warum nicht Sie in mysite direkt?
  • obwohl es nicht empfohlen wird, können Sie immer verwenden Sie den relativen Pfad, d.h. require('./builder/node_modules/....')
  • Yáñez Parareda hmm wusste ich nicht, die Logik, wie die Suche node_modules Los ist. Wenn ich wüsste, dass es Durchsuchungen im übergeordneten Verzeichnis auch... aber es ist ein problem, um Zugang zu einem Nachbar-Verzeichnis/.. Naja, jetzt werde ich das tun.
  • Es durchläuft den Weg von dem aktuellen Skript, bis er Sie findet node_modules/ - wenn das Verzeichnis nicht existieren, wenn es erreicht, root, schlägt fehl. require() akzeptiert auch einen Weg, die entweder beginnt mit ./ oder nur /. In diesem Fall, er behandelt es wie einen Dateipfad. Halten Sie im Verstand, NPM und Node.js sind zwei getrennte Systeme. Die node_modules/ Konvention ist ein Node.js Sache, und das package.json Konvention ist ein NPM Sache.
  • Dies wurde auch im Laufenden Diskussion über die NPM-repository auf Github. Es gibt einen cache-Module, die das Leben in Ihr home-Verzeichnis, obwohl derzeit alles kopiert wird, sowieso. Meiner Meinung nach, Module sollten symlinked aus diesem Verzeichnis, die eine Konstante Zeit den Betrieb. Aber die NPM-Besitzer scheinen nicht zu Stimmen 🙂
  • stackoverflow.com/questions/32260534/...

InformationsquelleAutor Julia | 2016-04-08
  1. 3

    Kurze Antwort

    Tun Sie es nicht. Lassen NPM zu arbeiten, wie es entworfen, um. Jedoch, um Platz zu sparen, können Sie löschen Sie den node_modules-Ordner auf Projekte, die derzeit ruhend, und erstellen Sie ihn mit einem einzigen Schuss npm install wenn Sie wechseln Sie zurück zu Ihnen.

    Begründung

    Selbst wenn Sie teilen Sie Ihre node_modules, werden Sie wahrscheinlich haben, Redundanzen in der it sowieso. Was werden Sie tun, um Ihnen ?

    Es ist das Wesen des NPM zu replizieren Module pro Projekt. Wenn Sie Graben sich in den node_modules Ordner-Struktur, können Sie feststellen, dass es sogar mehrere Replikationen der gleichen Bibliothek unter einem bestimmten Abhängigkeiten-Baum. Sagen Sie beantragt, zwei Module explizit, und diese beiden Module selbst zog eine Abhängigkeit, die kümmert sich um eine Menge Dinge, und wird deshalb als lib_DADDYMUMMY :

    node_modules
    + a_module_you_use v0.5
        + lib_DADDYMUMMY v0.1 (pulled as a dependency of this module)
    + another_module_that_you_requested v0.3
        + lib_DADDYMUMMY v0.1 (again ! pulled as a dependency of this other module)

    Dies ist praktisch, wenn Sie Ihre beiden module starten, die verschiedene Versionen von lib_DADDYMUMMY. Dies kommt in praktisch, wenn Sie halten lange gelebt Projekte ! Und die Hölle kennt, die in der JavaScript-Welt, mit sich schnell ändernden APIs, die Sie betrachten können, die meisten jedes anständige Projekt als langlebig. 🙂

    Könnte man sich vorstellen, dass alle Abhängigkeiten von allen geteilt, das Leben in einer flachen Struktur, mit mehreren Versionen einer Bibliothek Leben, neben einander und jeder finden, was er braucht da. Das repository genannt werden könnte, sagen wir, .m2. Aber das ist einfach nicht so, wie NPM funktioniert leider nicht.

    NPM ist der Auffassung, dass Speicherplatz Billig ist. Das ist der Preis für das helfen Sie verwalten Sie Versionen in Abhängigkeiten, der Abhängigkeiten, der Abhängigkeiten und die Abhängigkeiten der Abhängigkeiten der Abhängigkeiten. Ich denke, dass es zu einem erschwinglichen Preis für die Pflege des dirty jobs des Tages, wenn work und work2, als Ihr Leben, gehen Sie auf, nehmen divergierenden Wartung Pfade. Ich würde nicht versuchen immer in seiner Art und Weise erzwingen Sie eine halb-Maven-wie Ordner-Modell.

    • Danke 🙂 ja, ich verstehe. Vermutlich verschiedene komplexe Projekte brauchen eigene node-Module für jeden. Aber ich meist müssen aber ähnliche Aufgaben in Schluck für mehrere frontend-Projekte, wie die Kompilierung von sass, die Optimierung der Bilder, Zusammenführung mehrerer Dateien in ein usw... Ist es nicht besser, zu teilen node_modules alle diese ähnlichen Projekte?
    • Am Anfang ist es. Und wenn Ihr Projekt haben alle die gleiche Struktur, und immer bleiben die gleichen, dann wird es so sein. Allerdings, wenn work und work2 Zusammenführen von Dateien in sehr unterschiedlich aussehende Quelle Bäumen, und ein Jahr hinunter die Straße work2 gepflegt worden und nutzt nun neue SaSS, während work stützt sich auf Anweisungen, die OK waren, wenn Sie schrieb es aber, dass die SaSS Jungs beschlossen veraltet waren, werden Sie in Schwierigkeiten, und vor einer Menge von unnötigen Wartungsaufwand. 🙂
    • Danke, aber diese Lösung ist nicht die beste für mich... 🙂 Da npm install nimmt sich viel Zeit. Nicht Wert, wenn ich nur eine kleine änderung in einer Datei. Ich sehe hier eine Menge Warnungen NICHT teilen node_modules für mehrere Projekte... aber ich werde es versuchen 😀 naja, wenn ich Gesicht Probleme in Zukunft wird es erleben, dass ich sollte nicht so stur 😀 aber jetzt scheint es mir, dass es die beste Lösung für den schnellen Zugriff auf ähnliche Projekte und neue zu schaffen.
    • Eigensinn ist eine Qualität, bis man wird stur, stur. 😉 Take care !
    • Jedes mal, wenn das kopieren von 100MB in einen anderen Ordner oder Ausgaben von 10 Minuten die Installation alles von Grund auf ist der Raum/Zeit zu verschwenden.
    InformationsquelleAutor Mathias Dolidon
  2. 1

    Vielleicht sollten Sie Ihr Paket.json in Ihrem root-Verzeichnis(mysite/Paket.json)

    dann versuchen zu installieren node_modules auf der Wurzel.

    Zusätzlich, Sie schreiben gulpfile auf der gleichen dir.

    zB.

    mysite  
|- package.json  
|- node_modules  
|- gulpfile.js  
└─builder  
└─work  
└─work2

    Jedoch empfehle ich, dass Sie schreiben einen einzigen gulpfile für jedes Projekt.

    • Danke. Es wird immer mehr klar, für mich jetzt. Ich denke, die beste Lösung für meine situation ist node_modules in mysite und dann Unterverzeichnisse erstellen von mysite mit eigenen Paket.json und gulpfile.js
    InformationsquelleAutor katsew
  3. 0

    Fügen Sie den node_modules - Ordner in Ihrem mySite Verzeichnis.

    Alle npm packages wie gulp werden in Ihren work oder work2 Verzeichnis.

    Aber, jetzt(deine Ordner-Struktur) arbeiten-Ordner nicht finden können node_modules in Ihre übergeordneten Verzeichnis.

    InformationsquelleAutor w411 3
  4. -1

    Ein problem, warum Sie sollte nicht tun, dies ist wegen der Versionierung. Wenn die Module erfordern unterschiedliche Versionen des gleichen Pakets, wirst du auf Probleme stoßen. Ein Paket wird gewinnen, und es kann ein anderes Paket.

    Weiter, kommt man in das problem, dass merge die Listen Abhängigkeit in gewisser Weise - was bedeutet, dass Sie haben, um die Abhängigkeiten von work/package.json, work2/package.json usw. und dann installieren Sie alle auf einmal.

    Zusammenführen node_modules/ wird nicht Ihr problem lösen, entweder - glauben Sie mir, versuchen Sie nicht.

    • Ok, aber mindestens bei zwei Projekten, die erfordern, dass alle die gleichen Module, warum nicht gleichen Ordner Module auf die beiden zu?
    • da ist es schwer das zu managen. Das zweite der beiden Module erfordert eine andere Abhängigkeit, das Paket.json unterscheidet.
    InformationsquelleAutor Qix
Schreibe einen Kommentar