Ich bin sicher, dass andere ihre Gründe haben, aber der wichtigste Grund, warum ich nach webpack migriert (genauer gesagt webpack-dev-server), ist, weil es serves your bundle from memory (wie auf der Festplatte im Gegensatz) und seine Watcher recompile only the files you changed while reusing the rest from cache (im Speicher). Dies ermöglicht eine schnellere Entwicklung. Was ich meine ist, während ich aktiv Code bearbeite, kann ich Strg + s in Sublime Text, bis ich alt + Tab nach Chrome, es ist bereits getan Wiederaufbau. Ich hatte ein Grunzen + browserify + grunt-watch-Setup vorher, und es dauerte mindestens 5 Sekunden, um jedes Mal neu zu erstellen, wenn ich speichere (das ist, nachdem ich einige spezielle Optimierungen in grunt build gemacht habe). Trotzdem habe ich Webpack mit Schluck integriert, also habe ich einen Aufgabenläufer für mein Projekt bekommen.
EDIT 1: Ich möchte auch hinzufügen, dass die alten Grunt + Less/SASS + browserifizieren + Uglify + Grunt-Watch-Setup nicht gut skalieren. Ich habe von Grund auf an einem Großprojekt gearbeitet. Zuerst war es in Ordnung, aber als das Projekt wuchs, wurde es jeden Tag schlimmer. Irgendwann wurde es unglaublich frustrierend, darauf zu warten, dass der Grunzer alle Strophen fertigbaute. Es wurde auch offensichtlich, dass ich auf eine Menge unveränderter Dateien wartete.
Eine weitere nette kleine Sache ist, dass das Webpack Stylesheets in .js erfordert, die die Kopplung von Quelldateien im selben Modul herstellen. Ursprünglich haben wir Stylesheet-Abhängigkeiten eingerichtet, indem wir in .less-Dateien importiert haben, aber die Quelldateien im selben Modul getrennt und ein separates Abhängigkeitsdiagramm erstellt haben. Wiederum sind alle sehr eigensinnig und das ist nur meine persönliche Meinung. Ich bin mir sicher, dass andere anders denken.
EDIT 2: Alles klar nach einigen Diskussionen unten, lassen Sie mich versuchen, eine prägnante und weniger opinionated Antwort zu bieten. Eine Sache, die Webpack wirklich gut macht, ist, dass man den Cache beobachten, lesen, vorverarbeiten und aktualisieren kann und mit einer minimalen Menge von Datei-I/O und Verarbeitung arbeiten kann. Gulp-Pipe funktioniert ziemlich gut, aber wenn es um den Bündelungsschritt geht, muss es zwangsläufig alle Dateien aus einem temporären Verzeichnis lesen, einschließlich der unveränderten. Wenn Ihr Projekt wächst, wächst auch die Wartezeit für diesen Schritt. Auf der anderen Seite speichert der webpack-dev-server alles zwischengespeichert, so dass die Wartezeit während der Entwicklung minimal bleibt. Um diese Art von Speicher-Caching zu erreichen, muss das Webpack jedoch von der Überwachung bis zum Server abgedeckt sein, so dass es Ihre Vorverarbeitungs-Konfigurationen kennen muss. Sobald Sie Webpack so konfiguriert haben, dass Sie genau das tun, können Sie auch dieselben Konfigurationen wiederverwenden, um andere Builds als den Dev-Server auszuspucken. Also sind wir in dieser Situation gelandet. Davon abgesehen ist es genau das, was Sie von webpack erwarten, aber es bleibt Ihren persönlichen Vorlieben überlassen. Zum Beispiel mache ich keine Bildverarbeitung oder Lint in meinem Dev-Server. Tatsächlich ist mein Flusenschritt ein völlig anderes Ziel.
persönliche Präferenz. –
Es scheint ein seltsamer Trend in der node.js/javascript-Welt zu sein, den "best practices" zu folgen, und jedes Mal, wenn etwas Neues herauskommt, nennt eine Gruppe von Entwicklern/Bloggern es eine "Best Practice" und eine Menge Leute springen am Bord. –
Discusion scheint geschlossen zu sein, um die Antwort zu entschuldigen, so sorry für die unordentliche Nachricht. Für mich ist Webpack keine persönliche Präferenz. Verwende ich nicht wegen webpack-dev-server oder vielen netten sublimetext plugins. obwohl in einigen Fällen kann es die Verwendung von Aufgaben Läufer ersetzen, in meinem aktuellen Projekt verwende ich in Verbindung mit Schluck und sie zusammen sind ein Gewinner-Team. Das Gold von Webpack ist die Tatsache, dass Sie an Module denken können und es seine Abhängigkeiten verwaltet. – EricSonaron