Detailed explanation of Webpack server-side code packaging examples

Environment variables

Before, we often used process.env.NODE_ENV in the project, but this variable has an impact on webpack packaging, and it is optimized during production. . This article mainly introduces to you the sample code of Webpack server-side code packaging. The editor thinks it is quite good, so I will share it with you now and give it as a reference. Let’s follow the editor to take a look, I hope it can help everyone.

We will use other environment variables to distinguish:

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

Like this, NODE_ENV is always production.

And we actually For development/product environment, use the process.env.API_ENV variable (since this project is a koa interface service project, so you can name it like this and change it to anything, as long as you are happy).

Dynamic Configuration Packaging

Note

We used to write dynamic configuration loading in node.js back-end projects like this:

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

module.exports = options;

In order to improve readability and possible reuse of ENV, we will define a variable separately.

If you do this directly in the webpack packaged project, it will produce A question. For example, I have multiple configurations now:

• _development.js

• _test.js

• _production.js

• _staging.js

Even if the current environment I pass in is development, all configuration files will still be All are packaged in (but will never be executed). In this case, there is a risk of sensitive information being leaked.

The correct posture should be like this:

config/index .js

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

module.exports = options;

Modular packaging

For example, I have many For each module, for load balancing needs, or for customer-customized modular products, we need to package them in modules to prevent other modules (that will never be executed) from being packaged into the webpack bundle.

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

When loading on the server, it looks like this:

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

Then the ContextReplacementPlugin plug-in is needed to support it.

The code is as follows:

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

Advanced use

For example, in addition to the directories of each module in the src directory, there are also some common methods Directories of classes and hooks, such as: lib and hook. These two directories may be referenced by other submodules. Modify in the plug-in regular:

The code is as follows:

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

Compress the code and add source-map support

Uglifyjs or Uglify-es is actually not friendly to server-side code packaging and may cause packaging failure. Use babel- minify-webpack-plugin plug-in to replace.

Work with the source-map-support plug-in to support source code problem location.

Sample project source code: https://github.com/AirDwing/webpack -server-bundle

Related recommendations:

PHP simple system query module code package download_PHP tutorial

The above is the detailed content of Detailed explanation of Webpack server-side code packaging examples. For more information, please follow other related articles on the PHP Chinese website!