Output file size analyzer tool

[nevkontakte]

Is there a tool which can analyze GopherJS-generated JavaScript file and build a diagram of which packets contribute to the file size and through which dependencies they were pulled in? That is, something similar to https://github.com/webpack-contrib/webpack-bundle-analyzer, which can understand Go packages.

This is tangentially related https://github.com/gopherjs/gopherjs/issues/136, but is separate, since it's not about changing compiler as much as about understanding where file size comes from.

[dmitshur]

I was pretty sure I've seen a tool or a script that does this, but after spending a few minutes searching, I couldn't find it now. Hopefully someone else can recall, find, or create one.

It's not very hard to write a script, as the minifized .js file has one line per imported package.

For non-GopherJS size analysis, I've used goweight.

[nevkontakte]

Thanks, I also had the same feeling yet found nothing, but decided to ask before I try to write something myself :)

[nevkontakte]

After some experimentation, I was able to instrument GopherJS compiler to obtain necessary size information and generate an SVG TreeMap diagram out of it, which works both with minified and non-minified modes.

Here's an example diagram for github.com/gopherjs/gopherjs.github.io/playground:

Unfortunately, doing it as a completely standalone tool proven impossible since it needs some information that only exists at GopherJS compile time, so I'll have to submit a PR. Do maintainers have any preferences on introducing external dependencies? I have a fair bunch of code responsible for TreeMap diagram generation, which I could either put in my own repo, or make it a package in GopherJS codebase.

Meanwhile I still have some tests and cleanups to do while I'm awaiting the answer. If there's no answer, I'll assume putting that code into an external package is preferable.

[nevkontakte]

I am going to shelve this feature for the time being. I still think this would be a useful tool to provide, but it also adds a considerable maintenance burden, which we currently can't really afford.

Also having thought about it a bunch, improving sourcemap support and using existing source map visualizers might be an all-around better solution.