Heim  >  Artikel  >  Web-Frontend  >  Serverseitige Codeverpackung für Webpack

Serverseitige Codeverpackung für Webpack

巴扎黑
巴扎黑Original
2017-09-20 09:32:111668Durchsuche

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!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn