Maison > Article > interface Web > Explication détaillée des exemples d'empaquetage de code côté serveur Webpack
Variables d'environnement
Avant, nous utilisions souvent process.env.NODE_ENV dans le projet, mais cette variable a un impact sur le packaging du webpack, et elle est optimisée pendant la production. L'article vous présente principalement l'exemple de code de l'empaquetage 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 pour y jeter un œil, j'espère que cela pourra aider tout le monde.
Nous utiliserons 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 pour la production.
Dans notre environnement de développement/produit réel, nous utilisons la variable process.env.API_ENV (puisque ce projet est un projet de service d'interface koa, le nom peut donc être changé en n'importe quoi, tant que vous êtes satisfait
Emballage de configuration dynamique
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 ENV, nous définirons une variable séparément Faites cela directement dans le projet packagé par webpack Si c'est le cas. , un problème va survenir. Par exemple, j'ai maintenant plusieurs configurations :
// eslint-disable-next-line import/no-dynamic-require const options = require(`./_${process.env.API_ENV || 'development'}`); module.exports = options;Emballage modulaire
Par exemple , j'ai de nombreux modules dans le projet. Pour les besoins d'équilibrage de charge ou pour les produits modulaires personnalisés par le client, nous devons les empaqueter dans des modules pour empêcher d'autres modules (qui ne seront jamais exécutés) d'être empaquetés dans le bundle webpack
Lors du chargement sur le serveur, cela ressemble à ceci :
// config/_development.js exports.enabledModules = ['user', 'demo']; // 可能 src 目录下 还有其他模块目录, 如 'manage' 等
Alors c'est tout The ContextReplacementPlugin un plug-in est nécessaire pour le prendre en charge
// 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, le répertoire src En plus des répertoires de chaque module, 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 Modify dans le plug-in. Regular :
new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(lib|hook|${enabledModules.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.
Recommandations associées :
Téléchargement du package de code du module de requête système simple PHP _PHP Tutorial
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!