Split analyzer from the treemap UI code

[valscion]

This issue is a place to discuss and track a possible separation of webpack analyzer plugin code from the reporter UI code.

This idea was triggered by a proposal to add sunburst charts to the UI, where @th0r and me eventually thought it might be interesting to split these two concerns to distinct packages:

Or that the UI that is opened could be configurable, so that I could build a totally separate npm package that would only contain the UI parts that could be plugged into this packages webpack parts.

That's a very interesting idea and, at first glance, it won't be too hard to split analyzer from report UI.

We can move all current UI code from webpack-bundle-analyzer into, say, webpack-bundle-analyzer-treemap-reporter.
webpack-bundle-analyzer will be responsible only for analyzing bundle and feeding this info to reporter-plugins whose responsibility will be showing it in any way.

And the nice thing is reporter is not limited to some UI stuff - it can do anything it want with provided data!

[valscion]

I didn't hack on this on Christmas break but instead hacked on something completely different from work related matters to get a good vacation 🎅 . If I'll get to this, I'll let you know.

[valscion]

I'm gonna give this a go now. @bitpshr, would it be OK to try to get your beautiful sunburst chart to work first? It could be created as a webpack-bundle-analyzer-reporter-sunburst for example, if we'd want to try to prefix all the different reporters with webpack-bundle-analyzer-reporter- to ease discoverability.

[valscion]

Continuing from the refactoring done in #40, the current situation has a folder structure looking like this:

webpack-bundle-analyzer/
├── client
│   ├── components
│   └── vendor
├── lib
│   ├── bin
│   ├── chartData
│   └── viewer
├── node_modules
├── public
├── src
│   ├── bin
│   ├── chartData
│   └── viewer
├── test
│   ├── bundles
│   ├── src
│   └── stats
└── views

The only things reaching into top-level client, public and views folders are the root-level webpack.config.js and code under src/viewer.

Those folders and the webpack config form the implementation of the current treemap reporter.

I could extract the entire src/viewer/ folder to a new package, so that new reporters could create their own server and static strategies at will. This way all that the new reporters would need to do were to export two functions:

function generateReport(chartData, { openBrowser, reportFilename, bundleDir, logger })

and

function startServer(chartData, { openBrowser, port, logger })

The plugin's analyzerMode configuration option would select one of these. This way it would be up to the author of individual reporters to implement the static generation the way they would want to do it and to use whichever templating engine they'd like for the server build.

It might be a bit more difficult to try to extract things deeper down than these two functions, as it starts to get quite opinionated at that point and the separated reporters would be less powerful.

Take a look at the treemap implementation of these two functions:

• src/viewer/generateReport.js
• src/viewer/startServer.js

What do you think? Would this be a good split point, or should I aim for something less powerful?

[valscion]

Here's a proof of concept example showing what the code layout could look like: valscion#1

The reporter used could be customized with the CLI flag --reporter or -R, providing it either a npm package name or an absolute path to a file exporting generateReport and startServer functions as described in my post above.

Another way to customize the reporter would be to pass a module exporting those same functions as the reporter option for the plugin.

[valscion]

What do you think? Would this be a good split point, or should I aim for something less powerful?

I'll answer my own question:

I don't think this actually is a good split point, or at least not the best API.

I'd like to test out a monorepo approach for here, to really separate the reporter-treemap as its own npm package and to fine-tune the custom reporter API to be better.

For that, I'd also like to redo some build and test infrastructure currently on the repository to get better test coverage and to get a smooth build pipeline across all the packages this repository could contain.

I also wouldn't want to put many hours to this unless you would be okay with my changes, @th0r. How much space would you be willing to give me with the current infrastructure? Could I help you maintain this repository and change things around internally, targeting to a new v3 release that really would separate the reporter packages?

I really want to help and allow this plugin to work for most of the bundle related analyze use cases. To make that a reality, I would need to be able to improve the current test coverage and to make adding tests less painful than they currently are.

[th0r]

Sorry @valscion, I'm currently have very tough deadline on work so don't have time to look at it, but will do it as soon as I can!
Thanks!