style attribute javascript webpack commonschunkplugin

javascript - attribute - (Paquete web) Cómo dividir dependencias de módulos dinámicos



document.title jquery (2)

Acabo de darme cuenta de que si carga módulos dinámicamente utilizando require.ensure() , el webpack no analizará y fragmentará las dependencias juntas. Esto tiene sentido de alguna manera que uno podría argumentar, que el paquete web no puede saber si tales módulos se transfieren alguna vez, pero ¿podemos obligar al paquete web a hacer el trabajo de todos modos?

Ejemplo es:

app.js :

require.ensure([ ''module1.js'' ], ( require ) => { // at some point require( ''module1.js'' ); }, ''Module1''); require.ensure([ ''module2.js'' ], ( require ) => { // at some point require( ''module2.js'' ); }, ''Module2'');

módulo1.js

let io = require( ''socket.io-client'' );

módulo2.js

let io = require( ''socket.io-client'' );

El resultado de esta compilación es que ambos módulos obtienen la biblioteca completa de socket-io "enlazada" en sus fragmentos. Mi expectativa original era que el CommonsChunkPlugin atraparía esos requires y pondría esa gran biblioteca en una parte común.

new webpack.optimize.CommonsChunkPlugin( ''common'' ),

Sin embargo, no funciona. Por supuesto, siempre podría "resolver" esta dependencia manualmente, pero ¿esperaba que el webpack pueda hacer el truco de alguna manera?


Hasta ahora he encontrado una posible solución. Si usa el método require.include require.include() webpack para incluir (no evaluar) la " biblioteca compartida , aquí socket.io-client " también en el módulo principal, aquí app.js , el CommonChunkPlugin ahora podrá resolver las cosas correctamente.

require.include( ''socket.io-client'' ); // import io from ''socket.io-client''; also works require.ensure([ ''module1.js'' ], ( require ) => { // at some point require( ''module1.js'' ); }, ''Module1''); require.ensure([ ''module2.js'' ], ( require ) => { // at some point require( ''module2.js'' ); }, ''Module2'');

Sin embargo, esto no me parece correcto ya que se trata de una resolución manual de dependencias, que en realidad no es lo que quiero hacer con algo como Webpack .


La respuesta está oculta en la configuración de CommonsChunkPlugin

new webpack.optimize.CommonsChunkPlugin({ name: ''main'', // Important to use ''main'' or not specify, since ''main'' is default children: true, // Look for common dependencies in all children, minChunks: 2, // How many times a dependency must come up before being extracted });

children: true es la parte principal de esta configuración. De los documentos:

Si es cierto, se seleccionan todos los elementos secundarios de los elementos comunes.

Editar para async trozo común

Si desea descargar código común asincrónicamente en trozos, debe cambiar la configuración anterior con la adición de async: true

new webpack.optimize.CommonsChunkPlugin({ name: ''main'', children: true, minChunks: 2, async: true, // modification });

De los documentos sobre async :

Si es verdadero, se crea un nuevo fragmento async commons como hijo de options.name y hermano de options.chunks. Se carga en paralelo con options.chunks. Es posible cambiar el nombre del archivo de salida proporcionando la cadena deseada en lugar de true.

Ahora se crea un fragmento adicional que contiene solo socket.io-client de su ejemplo. Esto está cerca del ejemplo original en documentos de webpack .