Webpack-bundle-analyzer: Feature request: Generate analysis report file

[jasperck]

Issue description

Thanks for the awesome plugin, it truly helps us analyzing how our bundles had been built. Recently, I'm looking to analyze size of bundles in background or on CI. webpack-bundle-analyzer does great help for creating and storing the stats file from webpack, which gives me the opportunity to tweak the data in file. But webpack-bundle-analyzer only store the origin stats file, if we in some cases need information like gzip size, then there's no chance here.

In this case, the data which report.html used seems to be more valuable. Thus I think it would be awesome to make webpack-bundle-analyzer possible to generates and stores the data.

# Plugin options could be
{
  generateAnalysisFile: false // Boolean
  analysisFilename: 'analysis.json' // string
}

# CLI options could be
-a, --analysis <file>  Path to bundle analysis file that will be generated. (default: analysis.json)

Please feel free to close this if it's not something this plugin should response for. Otherwise, I'd be happy to create a PR for this. Also, suggestions and discussion are super welcome 🙏😀

[jasperck]

Hi @valscion, sorry it's been such a long time since I drafted this issue.
I just created a PR https://github.com/jasperck/react-gobang/pull/3/files for demo what report file could be generated from the webpack-bundle-analyzer that I stated. The PR shows 2 things,

1. Usage
   It just extend with a json mode, which tells webpack-bundle-analyzer generate report.json than report.html, and we could have the valuable analysis file.
2. Report file
   With kind of data, we could do something like group/filter/compare/...etc and take advantage of it not only for visualize it but also for other workflow benefit.

[
  {
    "label": "static/js/main.2bd70c8a.js",
    "statSize": 744348,
    "parsedSize": 358496,
    "gzipSize": 110526,
    "groups": [
      {
        "label": "node_modules",
        "path": "./node_modules",
        "statSize": 713880,
        "groups": [
          {
            "label": "react",
            "path": "./node_modules/react",
            "statSize": 7021,
            "groups": [
              {
                "id": 0,
                "label": "index.js",
...

Example

We integrated this with CircleCI and DangerJS, and now we can view bundle size changes within each PR, and all these were done automatically

Still, suggestions and discussion are super welcome 🙏😀

[burgalon]

this looks great. how can I test this?

[jasperck]

@burgalon Just like the example PR mentioned above https://github.com/jasperck/react-gobang/pull/3

// install the webpack-bundle-analyzer with patch
yarn add -D @jasperck/webpack-bundle-analyzer

// use with adding to the webpack config, for example
plugins: [
  ...
  new BundleAnalyzerPlugin({
    analyzerMode: 'json',
    defaultSizes: 'gzip',
    generateStatsFile: true,
  }),
],

then it will generate a analysis json file after the build.

[rafael-anachoreta]

This looks amazing and is pretty much exactly what I've been trying to do as well!
What would need to happen to get this in? 🙏

[valscion]

This sounds like a neat feature. I haven't replied yet as I'm torn on opening up the generated graph data JSON to be a part of the public API. I'm still keen on trying to separate the treemap visualization from the data generation on an architecture level (see https://github.com/webpack-contrib/webpack-bundle-analyzer/pull/97 for my last failed attempt). If I could get the visualization separated neatly from the data generation, adding new reporters such as "just write the data to a file" would have better support instead of needing a special flag to output the graph data.

So while I agree that enabling this sort of feature would be useful, I'm not sure if adding a new flag is the way to go.

[jasperck]

@rafael-anachoreta Thanks😂 The whole flow was done by webpack-bundle-analyzer, GiftHub API, CircleCI, Danger JS. The main purpose of webpack-bundle-analyzer here is only for creating the stats data which also is the indispensable part. If you or someone else are interested in it, I would be happy to open a repo and introduce more about it😊

[jasperck]

@valscion Cool, I agree separating data generation and visualization on architecture level should be a better way to achieve the goal! If this is in the roadmap then I put my hands up for it rather than extending a new flag. Decouple should leads to more flexibility here.
I will also take a look about #97 and related-PRs/issues, and see what I can contribute to it, or you could point me to the part if you want🙏

[valscion]

Thanks. I'm not sure if there's any clear contribution opportunities here, though — doing large changes would then be a review burden to maintainers and would likely end up as wasted effort.

I might have time and motivation to try the splitting again in the future

[RaoHai]

Hi ~ Because my work need to show this data on a dashboard, I have to generate the visualization data and crop it. I've implemented this feature on my fork and used it for production.

I think my fork is just a short-term solution and want to know if webpack-bundle-analyzer will eventually support it.

Like @jasperck, I can contribute to it, small changes, or separate visualizations and data, or add more visualizations.

[wadejensen]

Hello 👋 just wanted to register my interest in an option for a machine readable bundle size breakdown report as well.

Just wanted to check in case you'd changed your mind at all about making the current JSON representation public?
If not, is separating the data layer something you're likely to work on any time soon?

Regardless, thanks very much for maintaining webpack-bundle-analyzer. It's been a really useful tool 😄!

[valscion]

is separating the data layer something you're likely to work on any time soon?

I doubt that I will be doing work related to that in the near future

making the current JSON representation public?

I no longer have strong feelings about this, given I haven't got work done on the splitting done at all recently. Does @th0r have opinions about the JSON representation being public?