Leistungsprobleme mit Browserify + Watchify + Tsify + Gulp

Ich habe eine "mittlere" Typescript-Anwendung (wie in nicht trivial, aber nicht auf Unternehmensebene, viele tausend Zeilen) mit Abhängigkeiten von jQuery, React und SocketIO - neben anderen kleineren Bibliotheken.

Mein aktuelles gulpfile ist das:

Alles funktioniert wie erwartet, die Aufbauzeiten bei der Verwendung der Überwachungsaufgabe dauern jedoch viele Sekunden. Das Seltsame ist, dass meine Aufgabe meldet, dass die Neukompilierung der Skripte in weniger als 500ms (der Event-Handler beim "time" -Ereignis) stattfindet, aber wenn ich in meinem Kopf zähle, wird es erst drei bis vier Sekunden später beendet .

Beachten Sie, dass ich vor dem Einfügen meines vorhandenen TypeScript-Codes jQuery, React, Moment und die anderen Bibliotheken, die ich verwendet habe, sehr schnell geladen / gebündelt habe. Aus diesem Grund glaube ich nicht, dass die Verwendung eines separaten Anbieterpakets etwas beschleunigen würde. Das Ausgeben von Quellkarten wirkt sich auch nicht auf die Leistung aus.

Bevor ich zu browserify wechselte, benutzte ich gulp-typescript für die Kompilierung und benötigtejs für das Laden von Modulen. Diese Builds dauerten weniger als eine Sekunde. Requirejs verursachte jedoch aus anderen Gründen Probleme - und so oder so möchte ich von AMD zu CommonJS wechseln.

Für jetzt ist es keine große Sorge, aber während das Projekt wächst, könnte es sicherlich Probleme mit meinem Entwicklungsfluss verursachen. Bei einem Projekt nur so groß, wie lange dauert es noch, etwas Größeres zu verarbeiten?

Außerdem verursacht es auch Probleme mit Visual Studio. Dies ist eine ASP.NET 5-Anwendung, und Visual Studio besteht anscheinend darauf, dass die gebündelte JavaScript-Datei bei jeder Änderung neu geladen / erneut analysiert wird, was zu einer Verzögerung in der IDE für 1-2 Sekunden führt jede Änderung: zusätzlich zu den 3-4 Sekunden dauert es für die Neukompilierung selbst. Das Skript wird in meinem Ordner "wwwroot" gerendert, und es scheint keine Möglichkeit zu geben, den Unterordner "scripts" mit den ASP.NET 5-Tools zu "ausschließen".

Ich weiß, dass ich irgendwo etwas vermisse. Ein mögliches Problem ist, dass Tsify nicht die "Projekt" -Funktion des Typoskripts verwendet, um das Neuladen zu implementieren, was dazu führt, dass der TypeScript-Compiler jede Datei für jede Änderung neu verarbeitet.

Wie auch immer, ich kann nicht die einzige Person sein, die diese Tools über Spielzeugprojekte hinaus verwendet, also frage ich hier, ob jemand eine bessere Lösung hat; Seither läuft alles sehr gut.

BEARBEITEN --------------------------------

OK, ich werde meine eigenen Worte essen müssen. Builds sind jetzt auf ungefähr eine Sekunde reduziert, da ich meine Drittanbieter-Bibliotheken in einem eigenen Bundle bündle. Hier ist meine aktualisierte gulpfile (beachten Sie die neue Aufgabe dev.scripts.vendor und den Aufruf .external in der Funktion buildScripts)

Allerdings bekomme ich immer noch ein seltsames Problem. Mit deaktivierten Quellmaps (die sich jetzt anscheinend so schnell auswirken wie die Geschwindigkeit), meldet mein on ("time", () = & gt; {}) Callback 60-80ms für jeden Dateiwechsel, aber er bleibt immer noch für etwa a hängen zweite. Eine Sekunde ist über alles, was ich darauf warten möchte, also bin ich wieder besorgt, dass mit dem Wachstum des Projekts auch diese Wartezeit wachsen könnte.

Es wäre interessant zu sehen, wofür diese zusätzliche Sekunde der Zeit verwendet wird, wenn die Veranstaltung etwas viel kleineres berichtet. Vielleicht fange ich an, ein wenig in die Quelle zu graben, da es scheint, dass niemand sofort die Antwort hat.

ANDERE AUSGABE Dies ist nur eine Nebenbemerkung, aber debowerify funktioniert nicht mehr damit. Wenn Sie debowerify + bower verwenden, wird das erforderliche Modul in der endgültigen Ausgabe weiter gerendert, selbst wenn dieses Modul in der "externen" Liste aufgeführt ist. Im Moment kann ich mit diesem Setup nur npm-Module verwenden, es sei denn, es ist OK, meinem App-Paket mehr Kompilierungszeit hinzuzufügen.

Außerdem habe ich gelernt, dass debowerify npm-Module überschreibt, und dass es auf der Verzeichnisliste von bower_components basiert, NICHT auf Ihrer bower-Konfigurationsdatei. Ich hatte jQuery in npm installiert und bootstrap nur in bower; Da Bootstrap jedoch jQuery als Abhängigkeit herunterzog, wurde das Bower-jQuery-Modul bevorzugt über den NPM-jQuery geladen. Nur ein Kopf für die Leute.