Separating a Manifest

Express Gateway - A microservices API Gateway built on top of Express.js - Interview with Vincenzo Chianese

When webpack writes bundles, it maintains a manifest as well. You can find it in the generated vendor bundle in this project. The manifest describes what files webpack should load. It's possible to extract it and start loading the files of the project faster instead of having to wait for the vendor bundle to be loaded.

If the hashes webpack generates change, then the manifest changes as well. As a result, the contents of the vendor bundle change, and become invalidated. The problem can be eliminated by extracting the manifest to a file of its own or by writing it inline to the index.html of the project.

Extracting a Manifest#

Most of the work was done already when extractBundles was set up in the Bundle Splitting chapter. To extract the manifest, define optimization.runtimeChunk as follows:


const productionConfig = merge([
    optimization: {
      splitChunks: {
runtimeChunk: { name: "manifest", },
}, }, ... ]);

The name manifest is used by convention. You can use any other name, and it will still work.

If you build the project now (npm run build), you should see something:

Hash: 2e1c61341de0fd7e0e5c
Version: webpack 4.1.1
Time: 3347ms
Built at: 3/16/2018 6:24:51 PM
                   Asset       Size  Chunks             Chunk Names
manifest.d41d.css 0 bytes 1 [emitted] manifest
0.73a8.js 160 bytes 0 [emitted] vendors~main.3af5.js 96.8 KiB 2 [emitted] vendors~main main.8da2.js 546 bytes 3 [emitted] main main.5524.css 1.2 KiB 3 [emitted] main vendors~main.3dd5.css 1.32 KiB 2 [emitted] vendors~main
manifest.8cac.js 1.81 KiB 1 [emitted] manifest 203 bytes 0 [emitted] 10 KiB 1 [emitted] manifest 235 KiB 2 [emitted] vendors~main 1.45 KiB 3 [emitted] main index.html 460 bytes [emitted] ...

This change gave a separate file that contains the manifest. In the output above it has been marked with manifest chunk name. Because the setup is using HtmlWebpackPlugin, there is no need to worry about loading the manifest ourselves as the plugin adds a reference to index.html.

Plugins, such as inline-manifest-webpack-plugin and html-webpack-inline-chunk-plugin, assets-webpack-plugin, work with HtmlWebpackPlugin and allow you to write the manifest within index.html to avoid a request.

Try adjusting src/index.js and see how the hashes change. This time around it should not invalidate the vendor bundle, and only the manifest and app bundle names should become different.

To get a better idea of the manifest contents, run the build in development mode or pass none to mode through configuration. You should see something familiar there.
To integrate with asset pipelines, you can consider using plugins like chunk-manifest-webpack-plugin, webpack-manifest-plugin, webpack-assets-manifest, or webpack-rails-manifest-plugin. These solutions emit JSON that maps the original asset path to the new one.
The build can be improved further by loading popular dependencies, such as React, through a CDN. That would decrease the size of the vendor bundle even further while adding an external dependency on the project. The idea is that if the user has hit the CDN earlier, caching can kick in like here.

Using Records#

As mentioned in the Bundle Splitting chapter, plugins such as AggressiveSplittingPlugin use records to implement caching. The approaches discussed above are still valid, but records go one step further.

Records are used for storing module IDs across separate builds. The problem is that you need to save this file. If you build locally, one option is to include it in your version control.

To generate a records.json file, adjust the configuration as follows:


const productionConfig = merge([
recordsPath: path.join(__dirname, "records.json"),
}, ... ]);

If you build the project (npm run build), you should see a new file, records.json, at the project root. The next time webpack builds, it picks up the information and rewrites the file if it has changed.

Records are particularly valuable if you have a complicated setup with code splitting and want to make sure the split parts gain correct caching behavior. The biggest problem is maintaining the record file.

recordsInputPath and recordsOutputPath give more granular control over input and output, but often setting only recordsPath is enough.
If you change the way webpack handles module IDs (i.e., remove HashedModuleIdsPlugin), possible existing records are still taken into account! If you want to use the new module ID scheme, you have to delete your records file as well.


The project has basic caching behavior now. If you try to modify index.js or component.js, the vendor bundle should remain the same.

To recap:

  • Webpack maintains a manifest containing information needed to run the application.
  • If the manifest changes, the change invalidates the containing bundle.
  • Certain plugins allow you to write the manifest to the generated index.html. It's also possible to extract the information to a JSON file. The JSON comes in handy with Server Side Rendering.
  • Records allow you to store module IDs across builds. As a downside, you have to track the records file.

You'll learn to analyze the build in the next chapter as it's essential for understanding and improving your build.

Next chapter
Build Analysis

This book is available through Leanpub (digital), Amazon (paperback), and Kindle (digital). By purchasing the book you support the development of further content. A part of profit (~30%) goes to Tobias Koppers, the author of webpack.

Need help?