5 plugins úteis para webpack

Olá Habr!

O webpack possui muitos plugins úteis que muitos desconhecem e não usam em seus projetos. Sob o corte, coletei 5 deles, eles podem simplificar bastante sua vida!

1. Plugin webpack de arquivos não utilizados

Em grandes projetos de front-end, sempre há muitos módulos nos quais é fácil se perder. Se você não verificar o projeto quanto a módulos não utilizados, mais cedo ou mais tarde ele acumulará arquivos indesejados que não são usados ​​em nenhum lugar.

Para saber sobre arquivos não utilizados em um projeto, adicione unused-files-webpack-plugin à sua configuração:

npm i unused-files-webpack-plugin 

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

Após a instalação, você receberá avisos sobre quaisquer arquivos não utilizados:

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

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

Referências:

→ Github
→ NPM

2. Plug-in webpack de caminhos sensíveis a maiúsculas

Durante o desenvolvimento no OSX, muitas vezes é possível confundir letras minúsculas e maiúsculas em um caminho ao importar um módulo. A montagem será montada em uma papoula, mas em outros sistemas sensíveis a maiúsculas e minúsculas ela cairá.

Se você quiser se livrar desse problema, precisará colocar o case-sensitive-caminhos-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(), ], }; 

Agora, ao importar um módulo com a caixa incorreta, você sempre receberá um erro:

 /* 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`. 

Esse problema também pode ser resolvido usando o plug - in eslint import / no-unresolved .

No texto datilografado, há uma opção semelhante para work - forceConsistentCasingInFileNames. Mas ela se comporta de maneira um pouco diferente: ela verifica se a importação do módulo de lugares diferentes não difere no caso, a própria exatidão do registro não é verificada.

Referências:

→ Github
→ NPM

3. Inspectpack

No seu projeto, pode surgir uma situação em que você e seus pacotes usam versões diferentes da mesma biblioteca. Em seguida, vários pacotes aparecerão no pacote, o que pode ser facilmente corrigido especificando as mesmas versões.

O Inspectpack o ajudará a encontrar essa situação imediatamente:

 npm i inspectpack 

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

Se você instalar o plug-in, um aviso será exibido quando aparecerem cópias do pacote:

 /* 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 

Funcionalidade semelhante é fornecida pelo duplicado-pacote-verificador-webpack-plugin . Mas há um problema: ele não mostra várias ocorrências da mesma versão da biblioteca, ou seja, o problema no exemplo no spoiler, onde existem várias versões idênticas do tslib, ele não consegue encontrar.

Referências:

→ Github
→ NPM

4. Plugin de dependência circular

Durante o desenvolvimento, algumas vezes há problemas na resolução de dependências - dois módulos são importados um ao outro e uma dependência circular é obtida. Isso pode acontecer implicitamente, através de uma cadeia de outros módulos. Em casos raros, dependências cíclicas são normais, mas provavelmente isso indica que há um problema na arquitetura do projeto.

Para ver imediatamente a dependência circular e removê-la, adicione circular-dependency-plugin:

 npm i circular-dependency-plugin 

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

Agora, quando uma dependência circular aparecer, você receberá um aviso:

 /* 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 

As regras de importação / sem ciclo para eslint e tslint-no-circular-imports para tslint resolvem um problema semelhante. Este último, no entanto, não tem a capacidade de ignorar importações de tipos, interfaces e classes que são usadas apenas para digitação - você precisará escrever tslint: disable.

Referências:

→ Github
→ NPM

5. Velocidade medida plugin webpack

Em projetos grandes que consistem em várias centenas de arquivos, a montagem pode levar vários minutos.

O Speed-measure-webpack-plugin ajudará a medir todas as etapas da construção e 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({ /* ... */ }); 

A saída da compilação incluirá informações sobre o tempo total de compilação, o tempo de execução de cada plug-in e cada cadeia de carregadores:

  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 /* ... */ 

Ele me ajudou a encontrar um problema com a velocidade de minificação do TerserPlugin: removi várias configurações que quase não tinham efeito sobre o tamanho dos arquivos resultantes e a acelerei por alguns segundos.

Referências:

→ Github
→ NPM