Emballage de code côté serveur Webpack

Cet article présente principalement l'exemple de code du packaging de code côté serveur Webpack. L'éditeur pense qu'il est assez bon, je vais donc le partager avec vous maintenant et le donner comme référence. Suivons l'éditeur et jetons un coup d'œil.

Variables d'environnement

Avant, nous utilisions souvent process.env.NODE_ENV dans le projet, mais cette variable Ce packaging Webpack a un impact et est optimisé lors de la production

Nous utiliserons donc d'autres variables d'environnement pour distinguer :

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

Comme ça, NODE_ENV est toujours en production.

Et notre environnement de développement/produit actuel utilise la variable process.env.API_ENV (car le projet est un projet de service d'interface koa, il est donc nommé comme ceci, vous pouvez le changer en n'importe quoi , tant que vous êtes satisfait).

Emballage de configuration dynamique

Remarque

Nous avions l'habitude de le faire dans node Dans les projets backend .js, le chargement dynamique de la configuration s'écrit généralement ainsi :

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

module.exports = options;

Afin d'améliorer la lisibilité et la réutilisation éventuelle de l'ENV, nous le définirons séparément A

Si vous faites cela directement dans un projet packagé webpack, cela posera un problème. Par exemple, j'ai maintenant plusieurs configurations :

• _development.js<. 🎜 >

• _test.js

• _production.js

• _staging.js

<). 🎜>La posture correcte devrait être comme ceci :

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

module.exports = options;

Par exemple, j'ai de nombreux modules dans le projet, et pour les exigences d'équilibrage de charge, ou pour les produits modulaires personnalisés par le client, nous devons les empaqueter dans des modules, pour éviter d'autres modules (qui ne seront jamais exécutés) d'être empaquetés dans le bundle webpack.

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

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

Le code est le suivant :

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

Par exemple, en plus des répertoires de chaque module dans le répertoire src, il existe également des classes de méthodes et des répertoires de hook courants, tels que : lib et hook Ces deux répertoires peuvent être référencés par d'autres sous-modules. Modifiez-les dans le plug-in régulier :

Le code est le suivant :

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

Uglifyjs ou Uglify-es est en fait destiné au packaging de code côté serveur. Il n'est pas convivial et peut provoquer un échec de packaging. Utilisez plutôt le plug-in babel-minify-webpack-plugin.

Coopérez avec la carte source. -Plug-in de support pour prendre en charge l'emplacement du problème de code source.

Exemple de code source du projet : https://github.com/AirDwing/webpack-server-bundle

Ce qui précède est tout le contenu de cet article. J'espère qu'il sera utile à l'apprentissage de chacun. J'espère également que tout le monde soutiendra le script Home.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!