Introduction of 01.

This chapter is less, but more can be extended.

Projects are definitely context-specific, and you can package the JavaScript you need according to the context

I know of three general ways

  1. differentconfig, the use ofmerge, directly on the command line--configTo implement different packaging methods
  2. Write a packaged function, check the various environment variables on the command line, and then execute the package
  3. Depending on the server’s environment variables, through the plug-inwebpack.definePluginTo achieve sharing at both ends.

The first one is the one I use the most, because the project is not that complicated, and often the difference is whether source-map is enabled, whether compression is enabled, and so on. You don’t even need to use merge, just copy two copies and make changes.

The second one, the third one I haven’t used.

02. About merge usage.

First remove the common parts from webpack.config.js to three. Webpack.config.js.

I deleted it on my side

{
    mode: "development",
    devtool: "source-map"
}
Copy the code

Then install the WebPack-Merge plug-in.

npm install webpack-merge --save-dev
Copy the code

Create webpack.dev.config.js & webpack.pro.config.js

webpack.dev.config.js

const merge = require("webpack-merge").merge;
const baseConfig = require("./webpack.config");

module.exports = merge(baseConfig, {
    mode: "development",
    devtool: "source-map"
});
Copy the code

webpack.pro.config.js

const merge = require("webpack-merge").merge;
const baseConfig = require("./webpack.config");

module.exports = merge(baseConfig, {
    mode: "production"
});
Copy the code

Finally, change package.json

"dev": "webpack --config webpack.dev.config.js",
"pro": "webpack --config webpack.pro.config.js"
Copy the code

And that’s it, and the difference comes out when you compile it.

03. Command line mode

You will not use the entire command line directly. You will use the command line to help generate config.

Command line interface (CLI) here is the concrete document, where you can pass in environment variables, along with flags

Let’s just change the code.

New webpack. Env. Config. Js

const merge = require("webpack-merge").merge; const baseConfig = require("./webpack.config"); module.exports = env => { console.log(env); let config = {}; config.mode = env.development ? "development" : "production"; if(! env.min) { config.devtool = 'source-map'; } return merge(baseConfig, config); }Copy the code

I set two parameters development & min, and here is the code to call

webpack --config webpack.env.config.js --env=development --env=min
Copy the code

This allows you to control the generated schema and whether the Source Map is enabled.

This is what you can do with environment variables, and with environment variables and the configuration we’ve written, you can configure config more flexibly.

04. webpack.definePlugin

www.webpackjs.com/plugins/def…

This is the official document, Webpack has this plug-in, in fact, is essentially to give webpack code an environment variable, after all, pure front-end project how to environment variables

new webpack.DefinePlugin({
  wao: JSON.stringify("aaaa")
})
Copy the code

Then use it in your code

console.log(wao);
Copy the code

When you compile it, it becomes

console.log("aaaa");
Copy the code

One thing to note

  • If value is a string, it will be treated as a code fragment
  • If value is not a string, it will be stringify(including the function)
  • If value is an object, all keys are defined the same way.
  • If the key has atypeofPrefix, which is defined only for typeof calls.

So I used json.stringify

In fact, it is quite simple, so how does he synchronize environment variables at both ends of the item? I began to think that there is some high-end method..

Import the same file, you can import config.

04. Summary

Environment variables are well known, they’re on every system, whether it’s Windows or Linux or whatever. But to understand that you need to understand the scope of the environment variables.

  1. The environment variables of a commonly configured system are system-based
  2. In back-end code (Java, NodeJS), its environment variables exist only for the lifetime of the code
  3. webpackThe environment variables in the command line only exist in the configuration file, which is passed inenv
  4. webpack.DefinePluginAnd only in thewebpackIn this tool, giveJavaScriptCreate an environment variable, but you can do it yourself, just create a file. It just doesn’t have to be introduced every time

Multi-endpoint synchronization is when Webpack introduces the.env file of your backend code, enabling both sides to use the same set of environment variables.

So they’re all environment variables but they have different uses.

3 is flexible configuration for environment variables. 4 is code specific.

Therefore, you can adjust your configuration strategy flexibly according to point 3. You can also do different code according to point 4 in different modes.

Something like that