5 complementos útiles para webpack

Hola Habr!

El paquete web tiene muchos complementos útiles que muchos desconocen y no usan en sus proyectos. Debajo del corte, recolecté 5 de estos, ¡pueden simplificar enormemente tu vida!

1. Complemento de paquete web de archivos no utilizados

En grandes proyectos front-end, siempre hay muchos módulos en los que es fácil perderse. Si no verifica el proyecto en busca de módulos no utilizados, tarde o temprano acumulará archivos basura que no se utilizan en ninguna parte.

Para saber acerca de los archivos no utilizados en un proyecto, agregue los archivos no utilizados-webpack-plugin a su configuración:

npm i unused-files-webpack-plugin 

 /* webpack.config.js */ const { UnusedFilesWebpackPlugin } = require('unused-files-webpack-plugin'); module.exports = { /* ... */ plugins: [ /* ... */ new UnusedFilesWebpackPlugin(), ], }; 

Después de la instalación, recibirá advertencias sobre los archivos no utilizados:

 src/ ├── index.js └── someFile.js ( ) 

 WARNING in UnusedFilesWebpackPlugin found some unused files: src/someFile.js 

Referencias

→ Github
→ NPM

2. Complemento webpack de rutas sensibles a mayúsculas

Durante el desarrollo en OSX, a menudo puede confundir letras minúsculas y mayúsculas en la ruta al importar un módulo. El ensamblaje se ensamblará en una amapola, pero en otros sistemas sensibles a mayúsculas y minúsculas se caerá.

Si desea deshacerse de este problema, debe poner mayúsculas y minúsculas-rutas-webpack-plugin:

 npm i case-sensitive-paths-webpack-plugin 

 /* webpack.config.js */ const CaseSensitivePathsPlugin = require('case-sensitive-paths-webpack-plugin'); module.exports = { /* ... */ plugins: [ /* ... */ new CaseSensitivePathsPlugin(), ], }; 

Ahora, al importar un módulo con el caso incorrecto, siempre recibirá un error:

 /* index.js */ import someFile from './SOMEFILE'; 

 /* someFile.js */ export default () => { console.log('Hello!'); }; 

 ERROR in index.js Module not found: Error: [CaseSensitivePathsPlugin] `SOMEFILE.js` does not match the corresponding path on disk `someFile.js`. 

Este problema también se puede resolver utilizando el complemento import / no- noresolved eslint.

En mecanografiado hay una opción similar para el trabajo: forceConsistentCasingInFileNames. Pero se comporta de manera un poco diferente: comprueba que importar el módulo desde diferentes lugares no difiere en el caso, no se verifica la exactitud del registro.

Referencias

→ Github
→ NPM

3. Paquete de inspección

En su proyecto, puede surgir una situación en la que usted y sus paquetes usan diferentes versiones de la misma biblioteca. Luego aparecerán varios paquetes del paquete en el paquete, que se pueden solucionar fácilmente especificando las mismas versiones.

Inspectpack lo ayudará a encontrar esta situación de inmediato:

 npm i inspectpack 

 /* webpack.config.js */ const { DuplicatesPlugin } = require('inspectpack/plugin'); module.exports = { /* ... */ plugins: [ /* ... */ new DuplicatesPlugin(), ], }; 

Si instala el complemento, aparecerá una advertencia cuando aparezcan copias del paquete:

 /* package.json */ { /* ... */ "name": "my-app", "dependencies": { "lodash": "4.1.0", "one": "1.2.3" } } 

 /* node_modules/one/package.json */ { /* ... */ "name": "one", "dependencies": { "lodash": "3.0.0" } } 

 /* index.js */ import _ from 'lodash'; import 'one'; /* ... */ 

 WARNING in Duplicate Sources / Packages - Duplicates found! ️ * Duplicates: Found 2 similar files across 2 code sources (both identical + similar) accounting for 703 bundled bytes. * Packages: Found 1 packages with 2 resolved, 2 installed, and 2 depended versions. ## bundle.js lodash (Found 2 resolved, 2 installed, 2 depended. Latest 4.1.0.) 3.0.0 ~/one/~/lodash scenario-new-webpack-new-npm-unflattened@* -> one@1.2.3 -> lodash@3.0.0 4.1.0 ~/lodash scenario-new-webpack-new-npm-unflattened@* -> lodash@4.1.0 

Funcionalidad similar es proporcionada por duplicate-package-checker-webpack-plugin . Pero hay un problema con él: no muestra varias ocurrencias de una versión de la biblioteca, es decir, El problema en el ejemplo bajo el spoiler, donde hay varias versiones idénticas de tslib, no puede encontrarlo.

Referencias

→ Github
→ NPM

4. Complemento de dependencia circular

Durante el desarrollo, a veces hay problemas para resolver dependencias: dos módulos se importan entre sí y se obtiene una dependencia circular. Esto puede suceder implícitamente, a través de una cadena de otros módulos. En casos raros, las dependencias cíclicas son normales, pero lo más probable es que esto indique que hay un problema en la arquitectura del proyecto.

Para ver inmediatamente la dependencia circular y eliminarla, agregue el complemento circular-dependency:

 npm i circular-dependency-plugin 

 /* webpack.config.js */ const CircularDependencyPlugin = require('circular-dependency-plugin'); module.exports = { /* ... */ plugins: [ /* ... */ new CircularDependencyPlugin(), ], }; 

Ahora, cuando aparece una dependencia circular, recibirá una advertencia:

 /* first.js */ import second from './second' /* ... */ 

 /* second.js */ import first from './first' /* ... */ 

 WARNING in Circular dependency detected: first.js -> second.js -> first.js WARNING in Circular dependency detected: second.js -> first.js -> second.js 

Las reglas de importación / sin ciclo para eslint y tslint-no-circular-imports para tslint resuelven un problema similar. Sin embargo, este último no tiene la capacidad de ignorar las importaciones de tipos, interfaces y clases que se usan solo para escribir; a menudo tendrá que escribir tslint: disable.

Referencias

→ Github
→ NPM

5. Plugin webpack para medir la velocidad

En proyectos grandes que consisten en varios cientos de archivos, el ensamblaje puede demorar hasta varios minutos.

Speed-measure-webpack-plugin ayudará a medir cada paso de compilación y a encontrar problemas:

 npm i speed-measure-webpack-plugin 

 /* webpack.config.js */ const SpeedMeasurePlugin = require("speed-measure-webpack-plugin"); const smp = new SpeedMeasurePlugin(); module.exports = smp.wrap({ /* ... */ }); 

La salida de compilación agregará información sobre el tiempo de compilación total, el tiempo de ejecución de cada complemento y cada cadena de cargadores:

  SMP General output time took 48.97 secs SMP - Plugins TerserPlugin took 19.6 secs OptimizeCssAssetsWebpackPlugin took 2.65 secs MiniCssExtractPlugin took 0.261 secs VueLoaderPlugin took 0.216 secs /* ... */ SMP - Loaders mini-css-extract-plugin, and css-loader, and postcss-loader took 21.81 secs module count = 33 cache-loader, and babel-loader, and ts-loader, and tslint-loader took 21.63 secs module count = 240 /* ... */ 

Me ayudó a encontrar un problema con la velocidad de minificación de TerserPlugin: eliminé varias configuraciones que casi no tenían efecto en el tamaño de los archivos resultantes, y lo aceleré por un par de segundos.

Referencias

→ Github
→ NPM