Tips, you can set the build settings without compression to see what the code inside looks like.

Your label says vue, let’s talk about it from the vue demo I’ve been exposed to. First of all, a vue project must use vue, and secondly, the js of the project page, that is, how to instantiate vue and write the business.

If it is the traditional jquery development model, a page must contain at least two js, ​​one for jquery and one for page business.

Go back to the app, vendor, and manifest, and post the webpack configuration of the previous vue scaffolding

new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks: function (module, count) {
        // any required modules inside node_modules are extracted to vendor
        return (
          module.resource &&
          /\.js$/.test(module.resource) &&
          module.resource.indexOf(
            path.join(__dirname, '../node_modules')
          ) === 0
        )
      }
    }),
    // extract webpack runtime and module manifest to its own file in order to
    // prevent vendor hash from being updated whenever app bundle is updated
    new webpack.optimize.CommonsChunkPlugin({
      name: 'manifest',
      chunks: ['vendor']
    })

app.js is the entry js, vendor is the code block extracted by extracting the public module plug-in (the modular code part of webpack itself), and the manifest is based on the vendor, and then extracts the parts that need to be changed frequently. , such as the content about asynchronous loading of js modules.

It can also be seen from the screenshot that the vendor file size is the largest because it contains the code of the entire vue framework and the modular code of webpack.

As for the manifest, it mainly includes some implementation methods of asynchronous loading (dynamically introducing js by creating scripts), and the content includes the file name and path of the asynchronous js.

I checked some information before. The main reason is that js changes will change the js file name in asynchronous loading and change frequently. Relatively speaking, codes such as vue libraries only need to be compiled and packaged once. If it is only packaged, If you become a vendor, frequent changes to js will cause the vendor to compile repeatedly, which is a bit wasteful, so the parts that will follow changes repeatedly are extracted as manifest files.

This is my personal understanding, please correct me if you have any questions

Most of what @Dont said is right, but there are a few points that I think need to be changed: 1. CommonsChunkPlugin extracts common parts instead of "frequently changing parts"; 2. After observation, webpack should be The last chunk produced by CommonsChunkPlugin injects the definition of webpackJsonp, as well as asynchronous loading related definitions, and this will involve the md5 of all entries and chunks , so it will "change frequently", and the default vendor of vue-cli is Packing all the dependencies under node_module will be very large. In a production environment, overly large files should try to use cache to speed up loading, but "frequent changes" are not conducive to caching, so in order to make the entry (here can be considered app.js ) changes are isolated outside the vendor. vue-cli makes an additional manifest chunk after the vendor, so that the entry will not affect the vendor as long as it does not introduce new packages in node_modules. ps: So it is actually related to compilation The number of times does not matter, all files will be compiled again every time they are packaged. The key points are large files, caching, and splitting of changed codes. The following instructions are only interpreted according to the default configuration of the vue-cli family bucket. If there are any errors, please point out:

.vue or
.js?), there is no such page Can't run. vendor.js: In the default configuration of vue-cli family bucket, this chunk is to package all the dependencies required (import) from node_modules/, so this is all the dependencies required (import) under node_modules/ js file manifest.js: The last chunk is injected with the definition of webpackJsonp and the definition related to asynchronous loading (webpack calls CommonsChunkPlugin to process the core of module management. Because it is the core, it must be loaded first, otherwise an error will be reported. ).

Simplification: Due to the default vendor packaging strategy, this chunk is very large. According to the default configuration, there is basically nothing to streamline. If you want to streamline it, you basically need to modify the packaging strategy of each chunk according to the actual project (try to reduce the size of the package to speed up the first step) screen loading)

Optimization: A single page is basically the same as streamlining. If there are multiple pages, I think it is better to customize the vendor's packaging strategy. After all, not all pages will use the full amount of third-party dependencies. Appropriately reducing the vendor's size can improve a lot. Loading speed.