Allow analysis of generated bundle and dependencies

[valscion]

This issue is a continuation from the Twitter thread discussing usage of webpack-bundle-analyzer with CRA.

webpack-bundle-analyzer can be used either as a CLI, providing it the stats.json webpack JSON output and the built files. With these, we are able to:

1. Show the sizes of each module as they are on disk
2. Show the sizes of each module after minifcation
3. Show the sizes of each module after minification and gzip

Here's an example I built from a project using create-react-app after first having to eject.

⏩ report.html.zip ⏪

The changes I had to do after ejecting are in this commit: valscion/arvontakone@fbbc306

EDIT: Here's a GIF of that visualization:

[valscion]

Ideally this wouldn't require any changes to the CRA code, but I don't think that is possible. We'd need to at least get our hands on the stats.json that webpack can output if ran with the --json flag.

Are we able to come up with some way of gaining access to the module stats from the outside, or would it fall under the category of providing configuration and being excluded from CRA?

[franklinjavier]

I highly recommend the Bundle Buddy tool from @samccone

https://twitter.com/franklinjavier/status/931324987654443008?s=17

[gaearon]

What's the latest thinking on this? Which tools work best?

[valscion]

I'm biased, naturally, but still think webpack-bundle-analyzer would be the best. I'm still contemplating about the best way to handle outputting stats.json from the build -- this issue webpack-contrib/webpack-bundle-analyzer#119 makes me a bit unsure how much work we'd need to do in CRA to get the stats.json out without issues.

I haven't forgotten about this issue here, though. When I've had time with webpack-bundle-amalyzer, I've worked on the next major version PR webpack-contrib/webpack-bundle-analyzer#97

[gaearon]

OK, let me know if you need something on our side (as long as it doesn't negatively affect build perf).

[valscion]

Sure, will do ☺️

[joshwcomeau]

A "lighter touch" could be to just have an option to output JSON, and then that JSON can be handled however the user sees fit (I prefer to use Chris Bateman's webpack visualizer).

I imagine an addition to package.json scripts like this:

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "build-stats": "react-scripts buildStats",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  }

build-stats will just create a stats.json in the root dir, which they can then use however they see fit. For the recommended webpack-bundle-analyzer plugin, this can be done through their CLI utility, by adding another script (in userland) to the package.json:

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "build-stats": "react-scripts buildStats",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject",
+    "analyze": "webpack-bundle-analyzer stats.json"
  }

I'm happy to work on this as a feature if folks agree this is the direction to go!

[valscion]

Yeah the stats.json is indeed what webpack-bundle-analyzer would also need. I think we've agreed that is a good direction. This point — "as long as it doesn't negatively affect build perf" — is the crucial one that might need some manual fiddling.

Feel free to work on this @joshwcomeau, it would be amazing ☺️

[valscion]

@joshwcomeau you probably want to be aware of this: webpack-contrib/webpack-bundle-analyzer#119

Basically, if a bundle is large enough, JSON.stringify on the stats object coming from webpack can crash the build for an out-of-memory error. Most likely this would also affect webpack CLI itself when ran with --json flag, as they seem to be using plain JSON.stringify, too: https://github.com/webpack/webpack/blob/30329fb3648537ddc801b71f14904a3e762d4ad4/bin/webpack.js#L370-L371

I haven't reproduced this error myself, but if you find something, I'd love to hear about it.

[joshwcomeau]

This point — "as long as it doesn't negatively affect build perf" — is the crucial one that might need some manual fiddling.

Right, so I was proposing we don't do it as part of the main build task; I have a hard time imagining it not affecting build perf, since it's non-trivial extra work being done. By having it as a separate task (eg. build-stats or something), you can run that task as-needed. In my experience, this isn't something that needs to be done with every build, it's more something you do occasionally when you notice your bundle getting bloated. As a bonus, that separate task might be even faster? Although for that, I'm really not sure, don't know enough (or, really, anything) about Webpack internals.

@joshwcomeau you probably want to be aware of this: webpack-contrib/webpack-bundle-analyzer#119

Ah, interesting! I've never run into that myself. Do you think it's something we need to be concerned about? It seems like a pretty edge-case thing (otherwise I'm sure I would have run into it by now). My instinct is that we proceed anyway, and hope that a fix is implemented within webpack shortly.

I'll spend some time tomorrow looking at this.

[trevorwhealy]

I'm in favor of the separate entry point npm script proposal by @joshwcomeau, #1858 (comment) - the webpack visualizer they're referring to and webpack-bundle-analyzer alike are both great because of their interactivity. I actually made a workaround with a similar approach #3518 that can be used without ejecting.

I don't think we need to be that concerned about build performance here because, in my experience, this is not information most users will find very useful on every recompile. Usually, I check these tools every few days to make sure that the bundle size hasn't grown much larger than expected, due to a recently added dependency.

[valscion]

Ah, interesting! I've never run into that myself. Do you think it's something we need to be concerned about? It seems like a pretty edge-case thing (otherwise I'm sure I would have run into it by now).

We should care, one way or the other. If we go the direction of adding a new react-scripts task (like the buildStats you proposed), then this is not crucial — building the project normally would still work. We could tell about this edge case in the documentation.

However, if we were to create the stats.json file on react-scripts build, that would change things. The error coming from JSON.stringify is not rescuable, so we couldn't just slap a try { } rescue block around the call, as the JSON.stringify call will crash the node process itself. It would be awful if some users of create-react-app with huge applications would no longer be able to build their app at all.

Nevertheless, both approaches could benefit if we'd change JSON.stringify to some other code supporting streaming JSON stringification. Mainly, it could be much faster if the stringification of a huge object would be chunked. https://github.com/philbooth/bfj package seems like a nice solution.

My instinct is that we proceed anyway, and hope that a fix is implemented within webpack shortly.

Hmm I'm not so sure about whether webpack would fix it in any short time period. If the stats.toJson method would start crashing, then I'd bet they would do something. But if it is only the stringifying part, then it seems like more of a power user feature to be able generate a big JSON file.