Heim > Artikel > Web-Frontend > Serverseitige Codeverpackung für Webpack
In diesem Artikel wird hauptsächlich der Beispielcode für die serverseitige Codeverpackung von Webpack vorgestellt. Der Herausgeber findet ihn recht gut, daher werde ich ihn jetzt mit Ihnen teilen und als Referenz verwenden. Folgen wir dem Editor und werfen wir einen Blick darauf.
Umgebungsvariablen
Früher haben wir im Projekt oft „process.env.NODE_ENV“ verwendet, aber diese Variable Ist die Webpack-Verpackung wirksam und wird während der Produktion optimiert?
Daher verwenden wir andere Umgebungsvariablen zur Unterscheidung:
new webpack.DefinePlugin({ 'process.env.NODE_ENV': '"production"', 'process.env.API_ENV': `"${process.env.API_ENV || 'development'}"` })
So, NODE_ENV ist immer Produktion.
Und unsere eigentliche Entwicklungs-/Produktumgebung verwendet die Variable „process.env.API_ENV“ (da das Projekt ein Koa-Schnittstellendienstprojekt ist, heißt es also so. Sie können es in alles ändern , solange Sie zufrieden sind).
Dynamische Konfigurationsverpackung
Hinweis
Früher haben wir es im Knoten gemacht In .js-Backend-Projekten wird das dynamische Laden von Konfigurationen im Allgemeinen wie folgt 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, werden wir es separat definieren A Variable.
Wenn Sie dies direkt in einem Webpack-Paketprojekt tun, verursacht dies ein Problem. Ich habe jetzt beispielsweise mehrere Konfigurationen:
_development.js
_test.js
_produktion.js
_staging.js
Auch wenn es sich bei der aktuellen Umgebung, die ich übergebe, um eine Entwicklungsumgebung handelt, werden alle Konfigurationsdateien weiterhin gepackt (aber niemals ausgeführt). In diesem Fall besteht die Gefahr, dass vertrauliche Informationen verloren gehen.
Die richtige Haltung sollte so 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 habe ich viele Module im Projekt, und für Lastausgleichsanforderungen oder für kundenspezifische modulare Produkte müssen wir sie in Module packen, um dies zu verhindern andere Module (die niemals ausgeführt werden) werden nicht in das Webpack-Bundle gepackt.
// config/_development.js exports.enabledModules = ['user', 'demo']; // 可能 src 目录下 还有其他模块目录, 如 'manage' 等
Wenn es auf den Server geladen wird, sieht es so aus:
// src/server.js // 动态加载启用的模块 enabledModules.forEach((mod) => { /* eslint-disable global-require,import/no-dynamic-require */ const routes = require(`./${mod}/route`); routes.middleware() |> app.use; });
Dann benötigen Sie das ContextReplacementPlugin-Plugin, um es zu unterstützen.
Der Code lautet wie folgt:
new webpack.ContextReplacementPlugin(/ src/, new RegExp(`^./(${enabledModules.join('|')})/.*$`))
Erweiterte Verwendung
Zusätzlich zu den Verzeichnissen jedes Moduls im src-Verzeichnis gibt es beispielsweise auch einige allgemeine Methodenklassen und Hook-Verzeichnisse, wie zum Beispiel: lib und Hook. Auf diese beiden Verzeichnisse kann von anderen Submodulen verwiesen werden. Ändern Sie sie im regulären Plug-in:
Der Code lautet wie folgt:
new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(lib|hook|${ aktiviertModules.join('|')})/ .*$`))
Komprimieren Sie den Code und fügen Sie Source-Map-Unterstü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.
Beispiel-Quellcode eines Projekts: https://github.com/AirDwing/webpack-server-bundle
Das Obige ist Ich hoffe, dass der gesamte Inhalt dieses Artikels zum Lernen aller beiträgt.
Das obige ist der detaillierte Inhalt vonServerseitige Codeverpackung für Webpack. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!