This article mainly introduces 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 and take a look.
Environment variables
Before, we would often use process.env.NODE_ENV in the project, but this variable is Webpack packaging has an impact and is optimized during production.
So, we will use other environment variables to distinguish:
1 2 3 4 | new webpack.DefinePlugin({
'process.env.NODE_ENV': ' "production" ',
'process.env.API_ENV': ` "${process.env.API_ENV || 'development'}" `
})
|
Copy after login
Like this, NODE_ENV is always production.
And our actual development/product environment uses the process.env.API_ENV variable (because the project is a koa interface service project, so it is named this way and can be changed. It can be arbitrary, as long as you are happy).
Dynamic configuration packaging
Note
We used to use node.js In back-end projects, dynamic configuration loading is generally written like this:
1 2 3 4 5 | const ENV = process.env.NODE_ENV || 'development';
const options = require (`./_${ENV}`);
module.exports = options;
|
Copy after login
In order to improve readability and possible reuse of ENV, we will define a separate variable.
If you do this directly in a webpack packaged project, it will cause a problem. For example, I now have multiple configurations:
_development.js
_test.js
_production.js
_staging.js
Even if the current environment I pass in is development, all configuration files will still be packaged (but will never be executed). In this case, there is a risk of sensitive information being leaked.
Correct The posture should be like this:
config/index.js
##
1 2 3 4 | const options = require (`./_${process.env.API_ENV || 'development'}`);
module.exports = options;
|
Copy after login
Modular packaging
For example, I have many modules in the project. For load balancing needs, or for customer-customized modular products, we need to package them in modules to avoid other modules (always will not be executed) is packaged into the webpack bundle.
1 2 3 | exports.enabledModules = ['user', 'demo'];
|
Copy after login
When loaded on the server, it looks like this:
1 2 3 4 5 6 7 | enabledModules.forEach((mod) => {
const routes = require (`./${mod}/route`);
routes.middleware() |> app. use ;
});
|
Copy after login
Then you need the ContextReplacementPlugin plug-in to support it.
The code is as follows:
new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(${enabledModules .join('|')})/.*$`))
Advanced use
For example, in addition to each The directory of the module, as well as some common method classes and hook directories, such as: lib and hook. These two directories may be referenced by other sub-modules. Modify in the plug-in regular code:
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 the babel-minify-webpack-plugin plug-in instead.
Cooperate with the source-map-support plug-in to support source code problem location.
Sample project source code: https://github.com /AirDwing/webpack-server-bundle
The above is the entire content of this article. I hope it will be helpful to everyone’s learning, and I also hope that everyone will support Script Home.
The above is the detailed content of Webpack server-side code packaging. For more information, please follow other related articles on the PHP Chinese website!