Skip to content

Output file size analyzer tool #982

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nevkontakte opened this issue Jun 19, 2020 · 4 comments
Open

Output file size analyzer tool #982

nevkontakte opened this issue Jun 19, 2020 · 4 comments
Labels
enhancement NeedsHelp Community contributions are welcome for this feature!

Comments

@nevkontakte
Copy link
Member

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 #136, but is separate, since it's not about changing compiler as much as about understanding where file size comes from.

@dmitshur
Copy link
Member

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
Copy link
Member Author

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

@nevkontakte
Copy link
Member Author

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:
image

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
Copy link
Member Author

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.

@nevkontakte nevkontakte added NeedsHelp Community contributions are welcome for this feature! and removed Proposal Hold labels Feb 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement NeedsHelp Community contributions are welcome for this feature!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants