About Webpack (1)--Environmental separation and modularization

Elementary articles and demos have been basically completed, the code has been uploaded to my github, if you are not very familiar with the use of Webpack, then suggest you look back to the next series, which includes the current project using frequent plug-ins, loader of the explanation. As well as the basic Webpack configuration, dependencies and so on. If you already have a certain amount of webpack use experience. Then you can read this article directly is absolutely no problem.

This series will focus on the advanced use of Webpack, the previous article explained some of the parts, will not repeat the explanation.

So, let's start with the environment and the directory structure, which you can get directly from GitHub:

The following is the current environment configuration version:

In the actual work, we will distinguish between different environments to implement different Webpack configuration code, in order to achieve the requirements of different environments, the current main environment is actually two, a development environment, a production environment. Development environment is more inclined to convenient debugging, development convenience, such as unloading. The production environment wants the code to be smaller, the HTTP requests less, and the page loading faster. Even sometimes the requirements of the two environments are mutually exclusive. That's why you need to configure different code depending on the environment.

Don't say much nonsense, let's go straight to the chase.

In the previous article, in order to make the static resources to find the correct path, we set a variable Webpath, then if you want to distinguish the environment, the value of the variable is certainly different, then how we command to make Webpath get a different value, actually very simple:

Modify the build command and the dev command in Package.json, plus a parameter, and then we can get to this parameter in Webpack.config.js by Process.env. This makes it possible to differentiate between different environments.

"Scripts": {  "test": "Echo \" Error:no test specified\ "&& exit 1",  "Build": "Set type= Build&webpack--mode Production ",  " dev ":" Set type=dev&webpack-dev-server--mode development " ,  " Version ":" Webpack-v "}

Then after modifying the commands in Package.json, we also need to modify the Webpath code in Webpack.config.js:

 /*   */ if  (Process.env.type = =" Build "  var  webpath= { /*   This address is now casually written.        , just to be different from the development environment, real on-line words to be changed to your online address  */  Publicpath:  "http://www.zaking.com/" }}   else  { var  webpath={publicpath: " http://192.168.199.124:9090/"}}  

So you can run different commands to try the results. Here's a brief explanation of what process.env is, and the process is a global environment variable for node, and Process.env.type is the type value you set in the Scripts command. More details are not here to say that there are obsessive-compulsive partners can go to see here: https://nodejs.org/dist/latest-v8.x/docs/api/process.html#process_process_env.

So environment demolition Locutionary is finished, how to modular configuration Webpack? In fact, it is very simple, it sounds more high-forcing lattice. Simply put the general variables in a separate JS file, and then through the export exposed interface, require introduced interface only! For example, you must have written a lot of these things in the Vue, and then simply say the drop.

We create a new folder similar to Webpack.config.js, named Entry.js (portal). Then we write the code for the ingress configuration in Entry.js:

Const ENTRY ={};   // Declare Path property entry.path={    main:'./src/main.js '  }// export the variable Module.exports = entry;

The module is then introduced in Webpack.config.js and the configuration code at the next entry is modified:

/* The path to the entry file is introduced here */  =  require ("./entry.js");   /* Entry File */ Entry:entry.path

This enables the so-called modularity, which is, of course, a simple example where complex configuration items may have a logically complex modular configuration. such as VUE-CLI, now you go to see the VUE-CLI code, you should also be able to read some, but its function is more complex, the module is more relevant. Then this article will be written here for the time being. The next one will show you how to pack a third-party class library and more practical skills that are closer to life. The code of this article has also been updated to GitHub, and later with the update of the article will synchronize the code in real time, easy to learn.

About Webpack (1)--Environmental separation and modularization