Sono sicuro che gli altri hanno le loro ragioni, ma la ragione principale per cui ho migrato a webpack (più specificamente webpack-dev-server), è perché serves your bundle from memory (in contrapposizione a disco), e la sua Watcher recompile only the files you changed while reusing the rest from cache (in memoria). Ciò consente allo sviluppo di essere molto più veloce. Quello che voglio dire è che, mentre sto modificando attivamente il codice, posso ctrl + s in Sublime Text, nel momento in cui ho alt + tab su Chrome, è già in corso di ricostruzione. Avevo già un setup grunt + browserify + grunt-watch, e ci sono voluti almeno 5 secondi per ricostruire ogni volta che salgo (cioè dopo aver fatto un sacco di ottimizzazioni specializzate in build grunt). Detto questo, ho ancora integrato il webpack con il gulp, quindi ho ottenuto un task runner per il mio progetto.
MODIFICA 1: Voglio anche aggiungere che il vecchio grunt + LESS/SASS + browserify + uglify + setup di grunt-watch non ha scalato bene. Stavo lavorando su un grande progetto da zero. All'inizio andava bene, ma poi, man mano che il progetto cresceva, peggiorava ogni giorno. Alla fine è diventato incredibilmente frustrante aspettare che il grunt finisse di costruire ogni ctrl + s. È anche apparso evidente che stavo aspettando un mucchio di file non modificati.
Un'altra bella cosa è che il webpack consente di richiedere fogli di stile in .js, che stabilisce l'accoppiamento di file sorgente nello stesso modulo. Originariamente abbiamo stabilito le dipendenze del foglio di stile utilizzando l'importazione in file .less, ma i file di origine scollegati nello stesso modulo e stabilito un grafico di dipendenza separato. Ancora una volta tutti questi sono altamente supponenti, e questa è solo la mia opinione personale. Sono sicuro che gli altri la pensino diversamente.
EDIT 2: Bene, dopo alcune discussioni di seguito, permettetemi di offrire una risposta più concisa e meno convinta. Una cosa che il webpack fa davvero bene è che può guardare, leggere, pre-processare e aggiornare la cache e servire con una quantità minima di I/O e elaborazione dei file. Gulp pipe funziona molto bene, ma quando si tratta di fare un passo in bundling, finisce inevitabilmente per dover leggere tutti i file da una directory temporanea, compresi quelli invariati. Man mano che il progetto cresce, anche il tempo di attesa per questo passaggio aumenta. D'altra parte, webpack-dev-server mantiene tutto memorizzato nella cache, quindi la quantità di tempo di attesa durante lo sviluppo è ridotta al minimo. Tuttavia, per ottenere questo tipo di memorizzazione nella cache, il webpack dovrà coprire da orologio a server, quindi sarà necessario conoscere le configurazioni di pre-elaborazione. Una volta che hai configurato il webpack per farlo, potresti anche riutilizzare le stesse configurazioni per sputare build diverse dal server di sviluppo. Quindi siamo finiti in questa situazione. Detto questo, esattamente quali passaggi si desidera che il webpack faccia sia ancora all'altezza delle preferenze personali. Ad esempio, non eseguo l'elaborazione delle immagini o il lint nel mio server di sviluppo. In effetti, il mio passo con la lanugine è un obiettivo totalmente separato.
preferenza personale. –
Sembra esserci una strana tendenza nel mondo node.js/javascript per seguire le "best practice", e ogni volta che esce qualcosa di nuovo, un gruppo di sviluppatori/blogger lo chiama "best practice" e un gruppo di persone salta a bordo. –
La discusione sembra chiusa per rispondere, mi dispiace per il messaggio disordinato. Per me il webpack non è una preferenza personale. Non uso perché webpack-dev-server o molti plugin sublimetext. anche se in alcuni casi può sostituire l'uso dei corridori di compiti, nel mio progetto attuale sto usando in congiunzione col gulp e loro insieme sono una squadra vincente. L'oro del webpack è il fatto che puoi pensare ai moduli e gestisce le sue dipendenze. – EricSonaron