Allow analysis of generated bundle and dependencies

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: https://github.com/valscion/arvontakone/commit/fbbc3069ef7a152bce6eb2087d91beeda7a9ec36

EDIT: Here’s a GIF of that visualization:

[samccone]

My 2 cents when it comes to exporting these types of perf/stats from build pipelines

TL;DR

Add the ability for users to output full source included sourcemaps – making it trivial to use any sourcemap compatible bundle analyzer.

---

less tl;dr

My current thinking is that the webpack stats object only gives a small subset of the entire picture and is coupled to the a specific build pipeline 😕 which encourages hyper specific tooling that is not portable across other bundle analysis pipelines.

What is the most common denominator when it comes to looking and understanding bundles then? I would say it is source-maps.

The nice thing about sourcemaps with embedded source (debug sourcemaps in webpack) is that the sourcemaps are a portable bundle representation that do a pretty excellent job of capturing the entire picture of what is in a bundle or bundles for a given application.

From a user’s perspective what kind of questions arise when they are looking at a bundle or sets of bundles?

Based on my user research these are the questions that continually pop up.

• What is in my bundle?
• What is the largest thing in my bundle?
• Is there duplication in my bundle?
• Is there duplication across multiple bundles?
• Within lib X that is a dep of my bundle what is eating up all the space?
• Why is lib X making it into my bundle.

Luckily of all these questions can be answered via source maps introspection except for (why is lib X making it into my bundle).

For this reason I think that if CRA wants to make it easy for users to understand their bundle without having to eject their webpack config, outputting debug source maps in dev mode by default and optionally outputting debug source maps for a prod build is a solid approach that will be maximally is portable across tools.

As always thanks for your time and everyone’s thoughts.

[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?