javascript - react - Flujo de trabajo de Webpack que divide el proveedor y el código de la aplicación de manera eficiente

webpack version

Question

He tenido problemas para encontrar suficientes documentos y ejemplos de Webpack para obtener un flujo de trabajo de desarrollo ideal para mi situación. Aquí están todas las características que harían ideal el flujo de trabajo:

1. Mirando, idealmente a través de Gulp, con almacenamiento en caché eficiente. (No creo que necesite reemplazar un módulo caliente y sospecho que podría no encajar bien en mi entorno de desarrollo).

2. Módulos de proveedores (en este momento tengo solo paquetes npm, no exponiendo todos los globales de UMD en su archivo principal, si se trata de eso) que son

   a. no analizado y compilado nuevamente durante el reloj (por lo que la recompilación es más rápida),

   segundo. no recibe un mapa fuente (por lo que las devTools del navegador son más rápidas de responder), y

   do. escriba en un paquete distinto de vendor.js que los navegadores pueden almacenar en caché por separado de los paquetes de aplicaciones.

3. Módulos de aplicaciones que son

   a. explícito sobre todas las dependencias (es decir, import React from ''react''; incluso si React está realmente expuesto globalmente o algo a través del n. ° 2),

   segundo. se vuelven a compilar durante la guardia, y

   do. recibo un mapa fuente

La mayoría de lo que he leído en la documentación o en los ejemplos no parece afectar este flujo de trabajo en la cabeza.

Si bien veo en los documentos cómo crear un paquete específico del proveedor (reproducido aquí: solución simple para compartir módulos cargados a través de NPM en múltiples paquetes Browserify o Webpack ), el ejemplo simple proporcionado no aborda las direcciones 2a y 2b.

No veo en los documentos ninguna forma de especificar diferentes configuraciones de compilación (mapas de origen, etc.) para diferentes fragmentos, o para crear paquetes de Webpack completamente separados con archivos de configuración separados que puedan referirse entre sí, a menos que globalicen todas las bibliotecas de proveedores y usándolos como externos (?), que no es ideal ...

Además, tengo curiosidad de saber si los usuarios de Gulp están usando gulp-webpack o en su lugar una configuración como la proporcionada en http://webpack.github.io/docs/usage-with-gulp.html . (No estoy seguro de cuán bien el webpack-dev-server encajaría en mi entorno de desarrollo, por lo que me gustaría gulp-watch si es posible).

¿Me estoy perdiendo algo que otros usuarios de Webpack conocen? ¿Cuál es la mejor manera de hacer esto?

O ¿ es posible que Webpack no sea la herramienta adecuada para el trabajo?

Answer 1

Mirando, idealmente a través de Gulp, con almacenamiento en caché eficiente. (No creo que necesite reemplazar un módulo caliente y sospecho que podría no encajar bien en mi entorno de desarrollo).

Utilice webpack-dev-server .

Realmente no necesitas Gulp para esto, pero puedes usar su Node API con Gulp (estoy haciendo eso).

Módulos de proveedores (en este momento tengo solo paquetes npm, no exponiendo todos los globales de UMD en su archivo principal, si se trata de eso) que son

a. no analizado y compilado nuevamente durante el reloj (por lo que la recompilación es más rápida),

No creo que los archivos sin modificar sean analizados o recompilados durante la observación.

segundo. no recibe un mapa fuente (por lo que las devTools del navegador son más rápidas de responder), y

No sé cómo hacer esto. Creo que los mapas fuente están todos dentro o fuera. Pero puede usar devtool: ''eval'' que funciona mucho más rápido que los mapas fuente.

do. escriba en un paquete distinto de vendor.js que los navegadores pueden almacenar en caché por separado de los paquetes de aplicaciones.

Creo que estás buscando split-by-name-webpack-plugin .

Módulos de aplicaciones que son

a. explícito sobre todas las dependencias (es decir, importar Reaccionar de ''reaccionar''; incluso si React está realmente expuesto globalmente o algo a través del n. ° 2),

Esto funcionará Para require bibliotecas expuestas globalmente, use externals opción de configuración externals .

segundo. se vuelven a compilar durante la guardia, y

Lo que ha cambiado, se volverá a compilar (si usa webpack-dev-server).

Esto no responde todas sus preguntas, pero espero que sea suficiente para averiguar si esto funciona para usted. No creo que "no ver las bibliotecas" sea un problema tan grande como dices (hay muy poca penalización de perfomance en la reconstrucción de módulos en caché) y si abandonas los mapas de origen y usas devtool: ''eval'' , diría que es realmente rápido. Finalmente, hay una nueva solución de observación en proceso para Webpack, por lo que es posible que desee darle un giro. Debería tener incluso mejor perf.