Flusso di lavoro del pacchetto Web che suddivide in modo efficiente il fornitore e il codice dell'app

Question

Ho avuto problemi a trovare documentazione ed esempi di Webpack sufficienti per eseguire l'hash di un flusso di lavoro di sviluppo ideale per la mia situazione. Ecco tutte le caratteristiche che renderebbero ideale il flusso di lavoro:

1. Visione, idealmente tramite Gulp, con efficiente caching. (Non credo di aver bisogno della sostituzione di moduli caldi e sospetto che potrebbe non adattarsi bene al mio ambiente di sviluppo.)

2. Moduli del fornitore (al momento ho solo pacchetti npm, non tutti espongono i globi UMD nel loro file principale , se si è arrivati ​​a quello) che sono

   a. non analizzato & ricompilati durante l'orologio (quindi la ricompilazione è più veloce),

   b. non ricevere una mappa del sourc (in modo che gli sviluppatori del browser siano più veloci a rispondere) e

   c. scrivere in un bundle distinto vendor.js che i browser possono memorizzare nella cache separatamente dai pacchetti di app.

3. moduli App che sono

   a. esplicito su tutte le dipendenze (ad es. import React from 'react'; anche se React è effettivamente esposto globalmente o qualcosa via # 2),

   b. sono ricompilati durante l'orologio e

   c. do riceve un sourcemap.

La maggior parte di ciò che ho letto nella documentazione o negli esempi non sembra aver colpito questo flusso di lavoro in testa.

Mentre vedo nei documenti come creare un pacchetto specifico del fornitore (riprodotto qui: Simple solution to share modules loaded via NPM across multiple Browserify or Webpack bundles), il semplice esempio fornito non indirizza 2a e 2b.

Non vedo nei documenti alcun modo per specificare diverse configurazioni di compilazione (sourcemaps, ecc.) Per diversi blocchi, o per creare bundle Webpack completamente separati con file di configurazione separati che possono fare riferimento l'un l'altro, a meno che non si globalizzi tutte le librerie dei fornitori e utilizzarle come esterni (?), che non è l'ideale ...

Inoltre, sono curioso che gli utenti di Gulp utilizzino lo standard gulp-webpack o invece un'impostazione simile a quella fornita in http://webpack.github.io/docs/usage-with-gulp.html. (Non sono sicuro che il webpack-dev-server si adatti al mio ambiente di sviluppo, quindi vorrei attenermi a gulp-watch se possibile.)

Mi manca qualcosa che altri utenti di Webpack conoscono? Qual'è il miglior modo per farlo?

O è possibile che Webpack non sia lo strumento giusto per il lavoro?

Answer 1

Visione, idealmente tramite Gulp, con memorizzazione efficiente della cache. (Non credo di aver bisogno della sostituzione di moduli caldi e sospetto che potrebbe non adattarsi bene al mio ambiente di sviluppo.)

Utilizzare webpack-dev-server.

Non hai davvero bisogno di Gulp per questo, ma puoi usare la sua API del nodo con Gulp (lo sto facendo).

moduli Vendor (In questo momento ho solo i pacchetti NPM, non tutti di loro di esporre globali UMD nella loro file principale, se è venuto giù per quella) che sono

a. Non analizzato & ricompilato durante orologio (così ricompilazione è più veloce),

Non credo che i file non modificati sarebbero stati letti o ricompilati durante orologio.

b. non ricevere una mappa di sourc (in modo che gli sviluppatori di browser siano più veloci per rispondere), e

Non so come fare questo. Penso che le mappe di origine siano o tutte dentro o fuori. Ma puoi usare devtool: 'eval' che funziona molto più velocemente delle mappe di origine.

c. scrivere in un distinto bundle vendor.js che i browser possono memorizzare nella cache separatamente dai pacchetti di app.

Penso che stiate cercando split-by-name-webpack-plugin.

moduli App che sono

a. espliciti su tutte le dipendenze (vale a dire l'importazione da Reagire 'reagire'; anche se Reagire è in realtà esposto a livello globale o qualcosa di via # 2),

Questo funzionerà. A require librerie esposte a livello globale, utilizzare externals config option.

b. vengono ricompilati durante l'orologio e

Ciò che è stato modificato, verrà ricompilato (se si utilizza webpack-dev-server).

Questo non risponde a tutte le vostre domande ma spero sia sufficiente capire se questo funziona per voi. Non penso che "non guardare le librerie" sia un problema così grande come dici tu (c'è pochissima penalità di perf sulla ricostruzione dei moduli memorizzati nella cache) e se butti delle mappe e usi devtool: 'eval', direi che è molto veloce. Infine, there's a new watching solution in the works for Webpack quindi potresti dargli un giro. Dovrebbe avere un risultato ancora migliore.