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

Remarque

Dans nos précédents projets back-end node.js, le chargement de configuration dynamique était généralement écrit comme ceci :

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 :

• _development.js

• _test.js

• _production.js

• _staging.js

Même si l'environnement actuel dans lequel je passe est le développement, tout reste Les fichiers de configuration seront tous empaquetés (mais ne seront jamais exécutés). Dans ce cas, il y a un risque de fuite d'informations sensibles

La posture correcte devrait être la suivante :

<. 🎜 >config/index.js

// 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 :

Utilisation avancée

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 :

Le code est le suivant :

Compressez le code et ajoutez la prise en charge de la carte source

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.

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

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!