microsoft/webpack-bundle-compare

A tool for comparing webpack bundle stats

@mixer/webpack-bundle-compare

This is a tool that allows you to compare webpack bundle analysis files over time. Check it out here.

Usage

The bundle comparison tool takes URLs of webpack stat outputs and displays them. You can use the JSON output from the webpack-bundle-analyzer, but we also include a plugin here if you don't use that package.

Using the Plugin

First, install the plugin.

npm install --save-dev @mixer/webpack-bundle-compare

Then, add it to your webpack.config.js file.

+const { BundleComparisonPlugin } = require('@mixer/webpack-bundle-compare');

...

   plugins: [
+    new BundleComparisonPlugin()
   ]

By default, this'll output a file named stats.msp.gz in your build output. This is a gzipped msgpack file--for large projects webpack bundle stats can get pretty big and slow down your build, so we try to make it fast. You can configure the output format and filename by passing options to the plugin:

new BundleComparisonPlugin({
  // File to create, relative to the webpack build output path:
  file: 'myStatsFile.msp.gz',
  // Format to output, "msgpack" by default:
  format: 'msgpack' | 'json',
  // Whether to gzip the output, defaults to true:
  gzip: true | false,
})

Once you have this file, you can upload it somewhere such as Azure blob storage, and serve it in the tool. The module exposes a convenient way to get a direct preloaded link in the tool:

const { getComparisonAddress } = require('@mixer/webpack-bundle-compare');
const link = getComparisonAddress([
  'http://example.com/stats1.msp.gz',
  'http://example.com/stats1.msp.gz',
])

console.log('See your comparison at:', link);

Contributing

Architecture

It's a React/Redux app. We pull webpack analysis JSON down from URLs, process them, and output UI. State is driven via Redux, and the parsing and unzipping of the (potentially very large) webpack stat files happen in a webworker. Actions sent in the redux state are mirrored to the webworker, and in turn the webworker and send actions which get fired back to the host application. The work we do atop the stats file is not particularly interesting--an assortment of parsing, walking, and graph generation functions.

Iteration

To develop against the UI:

1. Create a folder called "public/samples", and place JSON files in there. Or use the ones we already have preloaded.
2. Set the WBC_FILES environment variable to a comma-delimited list of the filenames you placed in there.
3. Running the webpack dev server via npm start will now serve the files you have placed in there.

webpack-bundle-compare's Issues

This repo is missing important files

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

out of memory crash when uploading a stats msgpack of ~10MB

I'm trying to import some very big stats file in msgpack and gzipped, but unfortunately the stats must be too big that the application runs out of memory. I've tried to debug the issue but it is very hard for me.

Unfortunately I can't share the stats file as it occurs on a private project. But I can tell you that the generated stats is ~10MB

How can I solve the problem? any support is very appreciated

Package not published/found on npm public registry

I really like this idea! I was planning to implement it for a project and I found out that NPM throws a 404 when I try to install it, perhaps it's published under another namespace? or not published at all?

https://www.npmjs.com/package/@mixer/webpack-bundle-compare

$ npm i @mixer/webpack-bundle-compare --save-dev
npm ERR! code E404
npm ERR! 404 Not Found: @mixer/webpack-bundle-compare@latest

Support for uploading stats file from local file system

Thanks for sharing this awesome tool! We've already integrated it into our build pipeline for Office Online.

One thing that would be great would be the ability to choose files from the local file system for comparison, similar to what webpack analyse does (though they don't support the URL blob upload). The scenario here would be for developers wanting to see the impact of a change in a local branch before publishing a PR.

Was thinking that the FileReader API should make this possible

Can you publish a new version with Webpack 5 support to npm?

Hi,

I'm looking to use this plugin with webpack 5. It seems this commit adds support for webpack 5 but it's not available on npm.

If you would be able to publish a new version that would be appreciated!

Thanks!

Requesting ideas to Improve the tree-shaking analysis

Hello, Thanks for the awesome compare tool 👏

I've noticed that the below code block is being used to understand if require (cjs) is being used instead of a esmodule and hence marking it as a non-treeshakable module

webpack-bundle-compare/src/client/stat-reducers.ts

Lines 188 to 201 in b719bbe

	export const getImportType = (importedModule: StatsModule) => {
	let flags = 0;
	for (const reason of getReasons(importedModule)) {
	if (reason.type) {
	flags |= reason.type.includes('cjs')
	? ImportType.CommonJs
	: reason.type.includes('harmony')
	? ImportType.EsModule
	: ImportType.Unknown;
	}
	}
	return flags;
	};

webpack-bundle-compare/src/client/stat-reducers.ts

Line 394 in b719bbe

if (moduleType & ImportType.EsModule && !(moduleType & ImportType.CommonJs)) {

Many node modules are still exporting cjs files but still take care of tree-shaking.
For e.g. using require('lodash/get') will make sure that only the files required for get function are bundled in the final bundle created by webpack
But this tool marks lodash as Not Tree-Shaken

This is hence leading to a manual analysis to cross-verify of all such modules reported by the tool.
Other such complaints for Not Tree-Shaken were for modules such as axios, css-loader, style-loader, @babel/runtime etc.,

Can someone please share the idea/motivation behind showing the Not Tree-Shaken alert for a better understanding and ideas on the improvement we can do so that users can see correct percentage of tree-shaken modules in the final dashboard

Thanks again for all the great work!!