The Namedmodulesplugin and Hashedmoduleidsplugin in Webpack2

To discuss the features of these two plugin in Webpack 2, start with a front-end resource caching scheme for projects that use Webpack packaging.

Typically in projects that use webpack, we use it to CommonsChunkPlugin package all dependent third-party packages into a vender chunk named. At the same time, in order to avoid chunkhash changes in chunk every time the project code is changed vender , we will also generate a separate manifest chunk.

For example, suppose we have a project in which the entry file is index.js . The contents are as follows:

import add from ‘./src/add‘;import leftPad from ‘left-pad‘;import jsonp from ‘jsonp‘;add(1, 2);

Usually our webpack.config.js files will have a configuration similar to the following:

const path = require(‘path‘);const webpack = require(‘webpack‘);module.exports = {  entry: {  ‘app‘: ‘./index.js‘,  ‘vender‘: [‘left-pad‘, ‘jsonp‘]  },  output: {    filename: ‘[name].[chunkHash].js‘,    path: path.resolve(__dirname, ‘build‘)  },    resolve: {        extensions: [‘.js‘]    },    module: {        ...    },  plugins:[         new webpack.optimize.CommonsChunkPlugin({            name: [‘vender‘, ‘manifest‘],            minChunks: Infinity,        })  ]};

At this point, by Webpack packaging, three files are generated:

Suppose we modify the ./src/add.js file and repackage it, we get:

Can see only app and manifest these two chunk Chunkhash changed, and vender the Chunkhash and before kept the same. This makes it vender possible to cache the client, thereby reducing the amount of client downloads.

But what if a new file is added?

Suppose we add a new file to the project ./src/add2.js . index.jsthe content is as follows:

import add from ‘./src/add‘;import add2 from ‘./src/add2‘;import leftPad from ‘left-pad‘;import jsonp from ‘jsonp‘;add(1, 2);add2(1);

Once again, you will get the following output:

This is inconsistent with what we expected because we did not modify the dependent third-party package, but vender Chunk's chunkhash also changed.

This result is caused by the introduction of a new module, which makes the module ID of some modules in the packaging process change. The change of module ID directly leads to the change of chunk content including these modules, which leads to the change of Chunkhash.

Take a look:

The module with module ID 3 in the blue box is our newly added module. Since it was inserted in the location of ID 3, the IDs of all subsequent modules have changed.

Now that we have found the cause of the problem, the solution is clear. That is to find a way to name the module ID that is unrelated to the sequence. The easiest thing to think about is based on the file name or the hash value of the document content. In fact, it is the function of Namedmodulesplugin and hashedmoduleidsplugin that is to be said today.

For example, we enable Hashedmoduleidsplugin in the project:

  plugins:[        new webpack.optimize.CommonsChunkPlugin({            name: [‘vender‘, ‘manifest‘],            minChunks: Infinity,        }),        new webpack.HashedModuleIdsPlugin()  ]

At this point, building the project again gets:

You can see that the ID of each module has become a small segment hashes value. At this point, add in the project ./src/add2.js . Rebuild to get output:

As you can see, the vender chunk Chunkhash and module IDs for each module remain consistent between the two builds. This results in an optimal caching effect.

NamedModulesPluginthe effect is similar and is no longer demonstrated here. All the code involved in this article can be found on GitHub.

The Namedmodulesplugin and Hashedmoduleidsplugin in Webpack2