Webpack 4 y dividiendo el archivo de configuración en módulos

Hola Habr! Hoy les contaré acerca de Webpack 4 con separación de código en módulos separados, así como soluciones interesantes que lo ayudarán a construir su ensamblaje webpack 4. más rápido. Al final, proporcionaré mi ensamblaje webpack básico con las herramientas más necesarias, que luego podrán para ampliar Este ensamblaje lo ayudará a comprender este material, y también puede ayudarlo a escribir su implementación más rápido y resolver posibles problemas más rápido.

La ideología principal de este ensamblado es la separación correcta del código dentro del archivo de configuración para la comodidad de uso, lectura y limpieza de webpack.config.js. Los módulos y complementos necesarios para las versiones de desarrollo y producción (así como para la separación de la funcionalidad en el archivo principal) se ubicarán en una carpeta de paquete web independiente y se importarán para conectarse a la configuración principal.

¿Por qué es necesario este enfoque?

Con el aumento gradual en el número de módulos, complementos, etc., que su ensamblaje construye en el paquete web, el archivo de configuración crece a pasos agigantados. Con el tiempo, este archivo se vuelve difícil de leer, y cambiarlo a un proyecto específico, si algunos módulos no se usan, se vuelve más difícil, pero desea algo universal. Por lo tanto, se requiere una organización clara del código.

Que necesitamos

Utilizaremos el complemento webpack-merge .

Creamos la carpeta webpack y sacamos todos los módulos individuales en archivos separados. Por ejemplo, webpack / pug.js, webpack / scss.js y exporta estas funciones desde ellos.

Archivo Pug.js

module.exports = function() { return { module: { rules: [ { test: /\.pug$/, loader: 'pug-loader', options: { pretty: true, }, }, ], }, }; }; 

El archivo webpack.config.js . En este archivo los conectamos, y con la ayuda de este complemento nos conectamos conveniente y rápidamente.

 const merge = require('webpack-merge'); const pug = require('./webpack/pug'); const common = merge([ { entry: { 'index': PATHS.source + '/pages/index/index.js', 'blog': PATHS.source + '/pages/blog/blog.js', }, output: { path: PATHS.build, filename: './js/[name].js', }, plugins: […], optimization: { … }, }, pug(), ]); 

Ahora, si tenemos una nueva tarea, para la cual necesitamos un nuevo módulo, complemento, cargador, lo transferimos al módulo (archivo) del hotel y lo colocamos en la carpeta del paquete web, y luego lo conectamos al archivo de configuración principal, manteniendo la configuración lo más limpia posible.

Configuraciones para producción y desarrollo

Ahora, con la ayuda del banal if, terminaremos nuestra separación, a la que apuntamos, y configuraremos nuestro paquete web para estos dos tipos de desarrollo, por lo que finalmente será conveniente usar esta herramienta, y también en el futuro podremos configurarlo de manera flexible y sencilla para cualquier otro proyecto, o expandir en el actual. Para exportar a un nodo (para el propio paquete web) en el paquete web 4, utilizamos la siguiente construcción:

 module.exports = function(env, argv) { if (argv.mode === 'production') { return merge([ common, extractCSS(), favicon(), ]); } if (argv.mode === 'development') { return merge([ common, devserver(), sass(), css(), sourceMap(), ]); } 

En el objeto común, conectamos lo que se usa tanto en el producto como en el desarrollo, y en las condiciones conectamos solo los módulos que son necesarios en estos casos.

Ahora me gustaría hablar sobre las características principales de webpack 4 con respecto a webpack 3

• Para un inicio rápido, webpack 4 no necesita webpack.config.js, ahora solo necesita un punto de entrada (index.js)
• En la nueva versión, la interfaz de línea de comandos de webpack está en un paquete separado y necesita instalar webpack-cli.
• Para ejecutar webpack 4, necesita (de lo contrario, será una advertencia) en los scripts especificar modo (modo de operación) - modo de producción o - modo de desarrollo, dependiendo de la clave, la operación del paquete web cambia. El modo de desarrollo tiene como objetivo acelerar la construcción. En la versión de producción, todo apunta a la minificación final del código.
• Para crear archivos common.js y common.css, CommonsChunkPlugin ya no se usa, splitChunks ahora es responsable de esto y se usa la siguiente construcción:
  
  

    optimization: { splitChunks: { cacheGroups: { 'common': { minChunks: 2, chunks: 'all', name: 'common', priority: 10, enforce: true, }, }, }, }, 

  
  En webpack 3, esto sería así en complementos:
  
  

   new webpack.optimize.CommonsChunkPlugin({ name: 'common ', }) 

  
  En consecuencia, en los fragmentos en HtmlWebpackPlugin nos conectamos (aquí sin cambios).
  
  

   plugins: [ new HtmlWebpackPlugin({ filename: 'index.html', chunks: ['index', 'common'], template: PATHS.source + '/pages/index/index.pug', }), ], 

  
  
• El siguiente punto importante, para crear sourceMap, ahora usamos el siguiente enfoque: creamos el archivo sourceMap.js en la carpeta webpack y lo conectamos en la versión de desarrollo, por ejemplo (como se mencionó anteriormente):
  
  

   module.exports = function() { return { devtool: 'eval-sourcemap', }; }; 

Ahora el enfoque de complementos: [new webpack.optimize.UglifyJsPlugin ({})] no funciona.

Con esto, me gustaría completar mi historia y proporcionar mi ensamblaje básico: un enlace a webpack 4, que probablemente lo ayudará en su trabajo y desarrollo. Gracias por su atencion!