javascript - guide - paquete de plugins comunes webpack vs webpack dll plugin
webpack webpack config js (3)
Estaba buscando la diferencia aquí también, pero realmente no creo que este sea el caso. Al menos, ya no.
Si echa un vistazo a la documentación del paquete web para bibliotecas de división de código, se menciona una forma de extraer un archivo de manifiesto similar. Según tengo entendido, esto es lo que está haciendo el DllPlugin, excepto que está un poco más implícito con el CommonsChunkPlugin.
El beneficio es que no necesita mantener múltiples configuraciones de Webpack para este tipo de funcionalidad.
Antes usaba el plugin de paquetes comunes de webpack para crear un paquete de proveedores que contenía bibliotecas de terceros como angular, reaccionar, lodash, etc., pero luego supe del plugin dll de webpack. Parecen hacer las mismas cosas, pero el complemento dll también te permite reducir el tiempo de compilación. Entonces estoy confundido, ¿necesito usar estos dos complementos juntos? ¿Debo usar el plugin Common Chunks para crear un paquete de proveedores en la compilación de producción y el plugin dll en la compilación de desarrollo? ¿O debería usar el complemento dll tanto en las versiones de producción como de desarrollo? Por favor ¿Podría explicar esto?
Perdón por la respuesta larga, pero esperemos que pueda ayudar a aclarar las cosas.
Fundamentos de CommonsChunkPlugin
El autor del proyecto define una serie de puntos de entrada a la aplicación que producirán un paquete cada uno. Ejemplos típicos son proveedores , polyfills , main , pero por ejemplo, su aplicación podría dividirse en varias "áreas" independientes que tiene sentido cargar por separado (como, por ejemplo, inicio de sesión, principal, configuración).
El autor del proyecto luego define cuál de esos paquetes, o uno separado, debe contener un código común a todos ellos. Eso es típicamente bibliotecas de terceros y sus propias utilidades compartidas en todos los puntos de entrada.
Luego es responsabilidad del complemento analizar y recopilar dicho código común, luego colocarlo en un paquete definido. Todos estos análisis y trabajos suceden una y otra vez cada vez que se inicia una nueva compilación y, en modo de vigilancia, cuando se modifica el código que se comparte y pasa a formar parte del paquete de recursos comunes.
Tal división es útil tanto para una compilación de desarrollo como para una compilación de producción. Pero para el entorno de desarrollo, digamos que el código de reconstrucción relacionado con proveedores y rellenos puede tomar bastante tiempo y puede ser un desperdicio cuando no estás realmente cambiando esas partes (asumiendo que el código de terceros del que dependes es más grande que tu propia base de código).
Fundamento de DllPlugin
Dado el mismo entorno, por ejemplo desarrollo, el autor del proyecto crea dos configuraciones de paquete web donde solía haber una. El complemento se puede aplicar al entorno de producción, aunque se puede decir que DllPlugin tiene más sentido en el desarrollo (ver a continuación).
La primera configuración de compilación de webpack es necesaria para los denominados DLL , que son más o menos similares al código común visto anteriormente, pero no exactamente. A mi entender, las DLL en su mayoría tienden a agrupar código de terceros (proveedores y polyfills) y no su propio código de utilidad compartido, pero una vez más esto es más una impresión y no una regla estricta. De todos modos, aquí el autor del proyecto debe agrupar el código que cambia con mucha menos frecuencia durante una sesión de desarrollo normal. La idea, en el entorno de desarrollo, es ejecutar esta compilación de vez en cuando, por ejemplo, cuando una dependencia cambia. Y generalmente depende del desarrollador disparar esta construcción cuando lo crea necesario.
La otra configuración de compilación de paquete web es necesaria para el código propio del proyecto o, de todos modos, el código que cambia regularmente mientras se realiza el trabajo de desarrollo. Esta es la versión real que el desarrollador ejecutará una y otra vez, o se ejecutará en modo vigilancia, y en este punto debería ser mucho más rápido en comparación con la versión única vista en el escenario de CommonsChunk.
Entonces, en general, parecen similares, pero te dejan atacar objetivos diferentes. Tanto, que podría considerar usar DllPlugin para su entorno de desarrollo (ventaja: tiempo de compilación corto), mientras usa CommonsChunkPlugin para producción (ventaja: tiempo de carga corto cuando la aplicación cambia). De nuevo, también podría usar DllPlugin también en producción, con el pequeño inconveniente de tener que ejecutar dos compilaciones en una fila: una para DLL, la siguiente para la aplicación.
HTH
Usas uno o el otro Aquí hay un artículo que describe cómo usar DllPlugin y hacia abajo en la parte inferior de la página. Puede ver métodos alternativos para lograr lo mismo. Te dice cuáles son las diferencias, así como las ventajas y desventajas. Esto debería ayudarte a comenzar.