5 plugins webpack utiles

Bonjour, Habr!

Le webpack possède de nombreux plugins utiles que beaucoup ne connaissent pas et n'utilisent pas dans leurs projets. Sous la coupe, j'en ai récupéré 5, ils peuvent grandement vous simplifier la vie!

1. Plugin webpack de fichiers inutilisés

Dans les grands projets frontaux, il existe toujours de nombreux modules dans lesquels il est facile de se perdre. Si vous ne vérifiez pas le projet pour les modules inutilisés, tôt ou tard, il accumulera des fichiers indésirables qui ne sont utilisés nulle part.

Pour connaître les fichiers inutilisés dans un projet, ajoutez le plug-in-files-webpack-plugin à votre configuration:

npm i unused-files-webpack-plugin 

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

Après l'installation, vous recevrez des avertissements sur tous les fichiers inutilisés:

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

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

Références:

→ Github
→ NPM

2. Plugin webpack chemins sensibles à la casse

Lors du développement sur OSX, vous pouvez souvent confondre les lettres minuscules et majuscules dans le chemin lors de l'importation d'un module. L'assemblage se réunira sur un coquelicot, mais sur d'autres systèmes sensibles à la casse, il tombera.

Si vous voulez vous débarrasser de ce problème, vous devez mettre le plugin sensible à la casse-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(), ], }; 

Maintenant, lorsque vous importez un module avec le mauvais cas, vous obtiendrez toujours une erreur:

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

Ce problème peut également être résolu en utilisant le plugin eslint import / no-unresolved .

En tapuscrit, il existe une option similaire pour work - forceConsistentCasingInFileNames. Mais il se comporte un peu différemment: il vérifie que l'importation d'un module de différents endroits ne diffère pas au cas où, l'exactitude même du registre n'est pas vérifiée.

Références:

→ Github
→ NPM

3. Inspectpack

Dans votre projet, il se peut que vous et vos packages utilisiez différentes versions de la même bibliothèque. Ensuite, plusieurs bundles du package apparaîtront dans le bundle, ce qui peut être facilement corrigé en spécifiant les mêmes versions.

Inspectpack vous aidera à trouver cette situation immédiatement:

 npm i inspectpack 

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

Si vous installez le plugin, un avertissement apparaîtra lorsque des copies du package apparaîtront:

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

Des fonctionnalités similaires sont fournies par duplicate-package-checker-webpack-plugin . Mais il y a un problème avec cela - il ne montre pas plusieurs occurrences d'une version de la bibliothèque, c'est-à-dire le problème dans l'exemple sous le spoiler, où il existe plusieurs versions identiques de tslib, il ne peut pas le trouver.

Références:

→ Github
→ NPM

4. Plugin de dépendance circulaire

Pendant le développement, il y a parfois des problèmes avec la résolution des dépendances - deux modules s'importent et une dépendance circulaire est obtenue. Cela peut se produire implicitement, via une chaîne d'autres modules. Dans de rares cas, les dépendances cycliques sont normales, mais cela indique très probablement qu'il y a un problème dans l'architecture du projet.

Pour voir immédiatement la dépendance circulaire et la supprimer, ajoutez un plugin de dépendance circulaire:

 npm i circular-dependency-plugin 

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

Maintenant, lorsqu'une dépendance circulaire apparaît, vous recevrez un avertissement:

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

Les règles d' importation / sans cycle pour eslint et tslint-no-circular-imports pour tslint résolvent un problème similaire. Cependant, ce dernier n'a pas la possibilité d'ignorer les importations de types, d'interfaces et de classes utilisées uniquement pour la frappe - vous devrez souvent écrire tslint: disable.

Références:

→ Github
→ NPM

5. Plugin webpack de mesure de vitesse

Dans les grands projets composés de plusieurs centaines de fichiers, l'assemblage peut prendre plusieurs minutes.

Le plugin Speed-Measure-Webpack vous aidera à mesurer chaque étape de construction et à trouver les problèmes:

 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 sortie de build ajoutera des informations sur le temps de build total, le temps d'exécution de chaque plugin et de chaque chaîne de chargeurs:

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

Il m'a aidé à trouver un problème avec la vitesse de minification de TerserPlugin: j'ai supprimé plusieurs paramètres qui n'avaient presque aucun effet sur la taille des fichiers résultants et l'ai accéléré de quelques secondes.

Références:

→ Github
→ NPM