There are two ways to build a multi-page application with Webpack. Multiple pages and multiple configurations. In this example, multi-page single configuration is adopted, that is, on the basis of single-page application configuration, the HTML-webpack-plugin in Entry and plugins can be modified.

The advantage of multi-page single configuration is that different pages can share the same code, making it easy to implement long caching. The disadvantage is that as the project becomes larger and larger, the packaging speed will decrease significantly; The nice thing about multi-page multi-configuration is that packaging is much faster and the parallel-Webpack plugin is available, but it’s not easy to implement a long cache of shared code, which shifts the cost of page loading to the user.

This article focuses on how to use WebPack to build multi-page applications. Therefore, the basic configuration of WebPack will not be detailed. To learn about webPack configuration, you can go to —- WebPack configuration based on Vue2.x (production environment ~).

First introduce the page structure:

First, a multi-page application must have multiple entries. So how to generate multiple entries based on the above project directory? Above:

You can see that our generated entries look like this:

  "views/template001/yz": "... In front of the (omitted)/SRC/views/template001 / yz/yz. Js. ""."views/template002/yz": "... In front of the (omitted)/SRC/views/template002 / yz/yz. Js. ""} // Therefore, the corresponding value of [name] is as follows:"views/template001/yz"
Copy the code

Given the structure of the project, the next thing to consider is what we want the generated directory structure to be when we package it, and we can’t do anything about it until we design the directory structure first.

In this case, I want the project path to package the results to look like this:

-dist -views (---- to place HTML files) - template00x-xx.html - CSS (---- to place CSS files) -views - template00x-xx.css-js (---- to place JS files) -views  -template00X -XX.jsCopy the code

Ok, so now we know the packaged directory structure. Next, what affects the packaged directory structure or the reference path of the page file? ###### several key words:

Output: {path: // The root directory generated by the package, generally named dist filename: // [name] corresponds to the key of the entry object one by one, but we can modify the path, such as'js/[name].js', that is, in the JS directory. If filename is not written in our multi-page application project, it will affect the path of the manifest.js file for the packaged Webpack runtime. Because Webpack loads the manifest file as an initial file, it will not be placed in a dynamically loaded chunk. ChunkFilename: // Dynamically loaded file, in this case refers to the js file that vendor and their respective pages need to reference}Copy the code

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · I is the key line · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

The htML-webpack-plugin can be used to customize the location of the packaging results, etc. In this case it is set as follows:

The chunks setup is particularly important in multi-page applications, as it specifies which JS files you need to pack into the page. If not specified, WebPack will by default place all js generated by packaging in each multi-page.

Next, let’s set up the packaging path for static resources. Above:

Notice that assetsPublicPath represents the publicPath in Output. This means that it represents the source path of the static resource reference. In this project, publicPath is “.. /.. /” means that to access the resource file, you need to go up two levels from the HTML file, because the directory structure of the project is “views/template00X/”. Remember? (Don’t remember? Look up at the path entries are generated from.

Knowing this, you know that to access a static resource file, you need to go back two levels, to the root directory level, dist, and then find the corresponding resource.

We have set the js access path above, but the CSS package path has to be set in the mini-CSs-extract-plugin, as follows:

Based on this, we have set the basic configuration for the multi-page application. Packaged dist directory on:

Why are manifest.js and Vendor.chunk. js placed directly under the JS hierarchy? First, we set up code splitting. Second, my own superficial understanding is that ~ manifest.js is the file that must be executed first when the page is run, so it won’t be a dynamically imported chunk and therefore packaged in tier 1. Why is it in the dist/js/ directory? Remember that we set “js/[name].js” to filename for output. Vendor is a chunk-level JS in the first place because it is the file on which the project runs, but it does not have to be loaded at the beginning of the page. Here is the code splitting configuration:

Tara ~ that’s all for today’s notes, good night ~