5 nützliche Webpack-Plugins

Hallo Habr!

Das Webpack enthält viele nützliche Plugins, die viele nicht kennen und in ihren Projekten nicht verwenden. Unter dem Schnitt habe ich 5 davon gesammelt, sie können dein Leben stark vereinfachen!

1. Webpack-Plugin für nicht verwendete Dateien

In großen Front-End-Projekten gibt es immer viele Module, in denen man sich leicht verlaufen kann. Wenn Sie das Projekt nicht auf nicht verwendete Module überprüfen, werden früher oder später Junk-Dateien angesammelt, die nirgendwo verwendet werden.

Um nicht verwendete Dateien in einem Projekt zu erfahren, fügen Sie Ihrer Konfiguration das Webpack-Plugin für nicht verwendete Dateien hinzu:

npm i unused-files-webpack-plugin 

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

Nach der Installation erhalten Sie Warnungen zu nicht verwendeten Dateien:

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

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

Referenzen:

→ Github
→ NPM

2. Webpack-Plugin für Groß- und Kleinschreibung beachten

Während der Entwicklung unter OSX ist es beim Importieren eines Moduls häufig möglich, Klein- und Großbuchstaben in einem Pfad zu verwechseln. Die Baugruppe wird auf einer Mohnblume zusammengebaut, aber auf anderen Systemen, bei denen zwischen Groß- und Kleinschreibung unterschieden wird, fällt sie herunter.

Wenn Sie dieses Problem beseitigen möchten, müssen Sie das Webpack-Plugin für Groß- und Kleinschreibung verwenden:

 npm i case-sensitive-paths-webpack-plugin 

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

Wenn Sie jetzt ein Modul mit der falschen Groß- und Kleinschreibung importieren, wird immer eine Fehlermeldung angezeigt:

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

Dieses Problem kann auch mit dem Import / No- Unresolved Eslint Plugin gelöst werden.

In Typoskript gibt es eine ähnliche Option für work - forceConsistentCasingInFileNames. Sie verhält sich jedoch etwas anders: Sie prüft, ob sich der Import des Moduls von verschiedenen Orten nicht unterscheidet, falls die Richtigkeit des Registers nicht überprüft wird.

Referenzen:

→ Github
→ NPM

3. Inspectpack

In Ihrem Projekt kann es vorkommen, dass Sie und Ihre Pakete unterschiedliche Versionen derselben Bibliothek verwenden. Dann werden mehrere Bundles des Pakets im Bundle angezeigt, die durch Angabe derselben Versionen leicht repariert werden können.

Inspectpack hilft Ihnen dabei, diese Situation sofort zu finden:

 npm i inspectpack 

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

Wenn Sie das Plugin installieren, wird eine Warnung angezeigt, wenn Kopien des Pakets angezeigt werden:

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

Eine ähnliche Funktionalität bietet das Duplicate-Package-Checker-Webpack-Plugin . Es gibt jedoch ein Problem: Es werden nicht mehrere Vorkommen einer Version der Bibliothek angezeigt, d. H. Das Problem im Beispiel unter dem Spoiler, wo es mehrere identische Versionen von tslib gibt, kann er nicht finden.

Referenzen:

→ Github
→ NPM

4. Circular Dependency Plugin

Während der Entwicklung treten manchmal Probleme beim Auflösen von Abhängigkeiten auf - zwei Module importieren sich gegenseitig und es wird eine zirkuläre Abhängigkeit erhalten. Dies kann implizit über eine Kette anderer Module geschehen. In seltenen Fällen sind zyklische Abhängigkeiten normal, dies weist jedoch höchstwahrscheinlich auf ein Problem in der Projektarchitektur hin.

Um die zirkuläre Abhängigkeit sofort zu sehen und zu entfernen, fügen Sie das zirkuläre Abhängigkeits-Plugin hinzu:

 npm i circular-dependency-plugin 

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

Wenn nun eine zirkuläre Abhängigkeit angezeigt wird, erhalten Sie eine Warnung:

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

Die Import- / No-Cycle- Regeln für eslint- und tslint-no-Circular-Importe für tslint lösen ein ähnliches Problem. Letzteres kann jedoch Importe von Typen, Schnittstellen und Klassen, die nur zum Tippen verwendet werden, nicht ignorieren. Oft müssen Sie tslint: disable schreiben.

Referenzen:

→ Github
→ NPM

5. Webpack-Plugin zur Geschwindigkeitsmessung

Bei großen Projekten, die aus mehreren hundert Dateien bestehen, kann die Montage bis zu mehreren Minuten dauern.

Das Speed-Measure-Webpack-Plugin hilft dabei, jeden Build-Schritt zu messen und Probleme zu finden:

 npm i speed-measure-webpack-plugin 

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

Die Build-Ausgabe fügt Informationen über die gesamte Build-Zeit, die Ausführungszeit jedes Plugins und jeder Loader-Kette hinzu:

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

Er half mir, ein Problem mit der Minimierungsgeschwindigkeit von TerserPlugin zu finden: Ich entfernte mehrere Einstellungen, die fast keinen Einfluss auf die Größe der resultierenden Dateien hatten, und beschleunigte sie um einige Sekunden.

Referenzen:

→ Github
→ NPM