Ausführliche Erläuterung der serverseitigen Webpack-Code-Paketierungsbeispiele

Umgebungsvariablen

Früher haben wir im Projekt häufig „process.env.NODE_ENV“ verwendet, aber diese Variable hat Auswirkungen auf die Webpack-Verpackung und wird während der Produktion optimiert Der Artikel stellt Ihnen hauptsächlich den Beispielcode für die serverseitige Codeverpackung von Webpack vor. Der Herausgeber findet ihn recht gut, daher werde ich ihn jetzt mit Ihnen teilen und als Referenz verwenden. Folgen wir dem Herausgeber und schauen wir uns das an. Ich hoffe, es kann allen helfen.

Wir werden andere Umgebungsvariablen verwenden, um zu unterscheiden:

new webpack.DefinePlugin({
 'process.env.NODE_ENV': '"production"',
 'process.env.API_ENV': `"${process.env.API_ENV || 'development'}"`
})

So ist NODE_ENV immer für die Produktion.

In unserem In der tatsächlichen Entwicklungs-/Produktumgebung verwenden wir die Variable „process.env.API_ENV“ (da es sich bei diesem Projekt um ein Koa-Schnittstellendienstprojekt handelt, kann die Benennung beliebig geändert werden, sofern Sie damit zufrieden sind

Dynamisches Konfigurationspaket

Hinweis

In unseren vorherigen Node.js-Back-End-Projekten wurde das dynamische Laden von Konfigurationen normalerweise so geschrieben:

const ENV = process.env.NODE_ENV || 'development';
// eslint-disable-next-line import/no-dynamic-require
const options = require(`./_${ENV}`);

module.exports = options;

Um die Lesbarkeit und mögliche Wiederverwendung von ENV zu verbessern, definieren wir eine Variable separat

Tun Sie dies direkt im von Webpack gepackten Projekt , wird ein Problem auftreten. Ich habe jetzt beispielsweise mehrere Konfigurationen:

• _development.js

• _test.js

• _produktion.js

• _staging.js

Auch wenn die aktuelle Umgebung, die ich übergebe, Entwicklung ist, ist alles still Die Konfigurationsdateien werden alle gepackt (aber nie ausgeführt). In diesem Fall besteht die Gefahr, dass vertrauliche Informationen verloren gehen

Die richtige Haltung sollte wie folgt aussehen:

config/index.js

// eslint-disable-next-line import/no-dynamic-require
const options = require(`./_${process.env.API_ENV || 'development'}`);

module.exports = options;

Modulare Verpackung

Zum Beispiel , Ich habe viele Module im Projekt, um Lastausgleichsanforderungen oder für kundenspezifische modulare Produkte zu erfüllen. Wir müssen sie in Module packen, um zu verhindern, dass andere Module (die niemals ausgeführt werden) in das Webpack-Bundle gepackt werden >

Beim Laden auf dem Server sieht es so aus:

// config/_development.js
exports.enabledModules = ['user', 'demo']; 
// 可能 src 目录下 还有其他模块目录, 如 'manage' 等

Dann ist es das ContextReplacementPlugin Zur Unterstützung ist ein Plug-in erforderlich.

// src/server.js
// 动态加载启用的模块
enabledModules.forEach((mod) => {
 /* eslint-disable global-require,import/no-dynamic-require */
 const routes = require(`./${mod}/route`);
 routes.middleware() |> app.use;
});

Der Code lautet wie folgt:

new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(${enabledModules.join('|')})/.*$`))

Erweiterte Verwendung

Beispiel: src-Verzeichnis Zusätzlich zu den Verzeichnissen jedes Moduls gibt es auch einige allgemeine Methodenklassen und Hook-Verzeichnisse, wie zum Beispiel: lib und Hook. Diese beiden Verzeichnisse können von anderen Untermodulen referenziert werden regulär:

Der Code lautet wie folgt:

new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(lib|hook|${enabledModules.join('|')})/.*$`))

Komprimieren Sie den Code und fügen Sie Quellkartenunterstützung hinzu

Uglifyjs oder Uglify-es dient eigentlich der serverseitigen Codeverpackung. Es ist nicht benutzerfreundlich und kann zu Verpackungsfehlern führen. Verwenden Sie stattdessen das Plugin „babel-minify-webpack-plugin“.

Kooperieren Sie mit der Quellkarte -Unterstützung des Plug-Ins zur Unterstützung der Problemlokalisierung im Quellcode.

Beispielprojekt-Quellcode: https://github.com/AirDwing/webpack-server-bundle

Verwandte Empfehlungen:

PHP-Codepaket für einfache Systemabfrage-Module herunterladen _PHP-Tutorial

Das obige ist der detaillierte Inhalt vonAusführliche Erläuterung der serverseitigen Webpack-Code-Paketierungsbeispiele. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!