Add HTML report / visualization option

[timdp]

The output of this plugin is definitely very informative. 👍

However, it's also a bit dry. There are a lot of opportunities for visualizations.

In the Webpack world, there's webpack-bundle-analyzer. Have you considered making the produced analysis object compatible with the visualization part of that?

[doesdev]

Glad the info is useful. I have to admit some bias on this issue. I have observed as well the desire for visualization of the information. For some indefensible reason I've never "liked" graphs and visualizations all that much :/

Not sure why, but that has been the primary hangup in putting something like this in place. I think this plugin would get allot more usage with some of that visualization action, so I fully support any pull requests to do it. I do have it on my radar to try and tackle eventually if no one else wants to grab that.

Given my inexplicable resistance to visualizations I've never bothered messing with d3 or the like. It would be a good skill to learn.

All that to say, any help that anyone wants to offer with this one will surely speed up getting some visualizations in place. Eventually though I do plan on getting to it.

[doesdev]

A few possible modules that could help with the visualizations.

https://github.com/jquintozamora/react-d3-treemap
https://github.com/mojoaxel/d3-sunburst
https://github.com/vasturiano/sunburst-chart

[timdp]

Anything visual is bound to trigger a discussion about the most informative representation. Personally, I'm a big fan of sunburst charts, so it's great that you already linked to some that I also had in my bookmarks.

In the broader sense though, I think it'd be very interesting to use the same data structure that Webpack does, so that their visualizations can just be applied as-is. I have no idea how feasible that is.

That said, I might already mock up a sunburst based on the current data structure.

[timdp]

Update: I've added sunburst-chart to our production code and I quite like it. I'll look into turning it into a PR.

[doesdev]

So, I've been thinking allot about this as I've been testing it more thoroughly. I did implement a test for it and put that into the feature/viz branch. I think I would be doing the community a disservice in integrating visualization in the library.

My core motivation in this library is to get the most accurate picture possible of the data. That is to say, ensuring that treeshaking is accurately reflected on a per-module basis and relationships are clearly defined. There are a couple other modules out there that speacialize in visualizing Rollup bundles. Specifically rollup-plugin-visualizer is the one I have in mind. It is well maintained and more widely adopted than this. However, it doesn't reflect treeshaking on a per module basis.

Selfishly I thought introducing visualizations here would give this module an edge in adoption, but in reality what would be best is for me to reach out to the maintainers and see if they might consider using this module as the engine for the data. Then we could work collaboratively to ensure the integration is tight, but this module could remain focused on aggregating the data as accurately as possible.

If I can find the time (currently doing some contract work on top of the day job) I'll try to put in a pull request or at least put together a good case for it as an issue.

Does that sound like a good approach?

[timdp]

I'm currently going through my backlog of GitHub issues and PRs. Sorry about the crazy late response.

I think what you're advocating is a separation of concerns, which naturally makes a lot of sense. I totally agree that this package's sole responsibility should be to act as a data source. It could for example have a plugin architecture that lets people use reporters of their choosing, much like e.g. mocha or listr. I'd still consider bundling in a sensible choice of reporters by default though, even if they're just dependencies.