Revisit the decision to allow webpack analyzer tools

[gaearon]

I haven't been following #3945 closely and it just got merged. But I'm not so sure this is a great idea (see #1858 (comment) for why).

I'll want to look at this again closer to shipping 2.x and decide whether to ship or remove this.

[audiolion]

I came looking to answer this question:

Given a PR, what changes were there to the bundle size overall and across various chunks

Very much like facebook/react

The PR providing the stats file will let me do that without ejecting, so I am in favor of it. Would source maps be able to provide this info?

[gaearon]

You can get this info by reading the file sizes from the files, no? I don't think you even need sourcemaps for that.

[valscion]

Yeah, I undersand if #3945 wouldn't in the end be what you'd like CRA to have. It does tie CRA closer to webpack specific tooling than what probably is the goal of CRA in the first place.

I haven't used much sourcemap-specific tooling, due to sourcemaps so easily getting broken and it only takes one bad configuration to break them.

I am biased, as I help maintain webpack-bundle-analyzer, but I have yet to see a tool that works on sourcemaps and allows us to visualize the post-gzip sizes of each chunk and module in a visually pleasing way.

I hope this situation will change in the future, and that we will see better tooling for sourcemap analyzing than what there currently are.

[joshwcomeau]

Hm, so yeah, I understand that the solution isn't ideal, since we want to avoid having webpack-specific tooling (after all, webpack should be an implementation detail and shouldn't affect the surface API). I thought it was agreed that the benefits outweighed that con, though.

I agree with the philosophy in #1858 (comment), but the reality is that the webpack-specific tooling is more helpful/insightful than sourcemap-specific tooling (at least, that's been my experience. If we can provide instructions for how to achieve the same result with the same ease-of-use, that's a different story).

It's discouraging to hear that this may not make it in to 2.0. It may not be evident from the small # of changed lines, but it still took a considerable amount of my time, over many months, during a time that I had a lot of things vying for my attention. I was happy to spend that time and energy, because I think it's an important feature, but I would not have spent it if I had known that the feature may not be released.

[gaearon]

I mean, I appreciate the work. I've literally not even tried this yet, so I want to make sure I play with it before it's shipped. I try to make sure to try all new features we add but I haven't had time to look at this one yet.

If the experience is good and the info itself is representative of the builds (and not misleading like webpack-specific tools commonly present it), I agree it's worth shipping in this form even if we remove it later (e.g. when there are better sourcemap-based tools).

[gaearon]

I haven't used much sourcemap-specific tooling, due to sourcemaps so easily getting broken and it only takes one bad configuration to break them.

Where can I learn more about this?

[bugzpodder]

Here is my notes on testing yesterday. This should have been done more throughly before merging but I did not realize using this was somewhat controversial at the time. In general I feel like we should not be adding unnecessary confusion to the users over features we add so I'd like ask others to test this as well and weigh in.

What I like over webpack-bundle-analyser over source-map-explorer:

• It shows you the all the chunk's information (also has a hidden left nav to select files). With source-map-explorer only ever display one chunk at a time. (you can specify main., vendor., or one of many chunks one at a time). Realistically most people only care about the main/vendor bundles so this isn't really a big deal I think?
• It has more information: stats, gzipped, parsed size over just parsed size for sourcemaps.
• Having it in one file is slightly easier to deal with if you want to compare before and after.
• It has slightly better resolution in terms of some assets, for example I have imported moment-timezone and webpack-bundle-analyser more correctly identified a json file that was bundled as belonging to moment-timezone (150kb) while soucemaps just lumped it into another random module!
  Both should be the same json.

What are similar:

• Both tools have similar UI, webpack-bundle-analyser has a hidden left bar to select file while source-map-explorer's tree navigation is a little bit cleaner.
• Both reports very similar +/- a few kb module parsed size and total parsed size in most respects (except for the exceptions I mentioned)

What I am concerned about webpack-bundle-analyser:

• It only takes account of the bundle size before uglify kicks in?
  This is somewhat well doumented: Webpack bundle analyzer does not accurately represent effects of tree-shaking in webpack 4 webpack-contrib/webpack-bundle-analyzer#161
  https://twitter.com/dan_abramov/status/866424533787586560?lang=en
  Realistically I have not being able to reproduce this in a meaningful way for vendor modules. I have not had a chance to test out main code.
• Somehow in the main bundle I am having all my modules showing up twice. One with just Stats size under the index.js + concatenated, and another one below it with a different stats size. This is confusing and I don't understand why: @valscion

[gaearon]

It only takes account of the bundle size before uglify kicks in? This is somewhat well doumented: webpack-contrib/webpack-bundle-analyzer#161 https://twitter.com/dan_abramov/status/866424533787586560?lang=en

This seems worrying if it's the case. I assumed that this has long been fixed given that folks kept pushing for that PR to get merged.

Indeed, we can't possibly ship this if chrisbateman/webpack-visualizer#31 is still an issue. This is a React project, and we'd be misreporting the size of React itself. This doesn't make sense. :-)

[gaearon]

Oh wait, https://github.com/chrisbateman/webpack-visualizer is a completely different project. So maybe it's not a problem for webpack-bundle-analyzer after all?

[audiolion]

You can get this info by reading the file sizes from the files, no? I don't think you even need sourcemaps for that.

Hey yeah absolutely, but getting gzipped sizes of webpack tree-shaken chunks and such? Not so simple without that stats file

[gaearon]

@audiolion I'm not sure I understand. The chunks are just JS files. You can read every file in static/js—those are your chunks. Then you can gzip them. In fact that's exactly what we do in our build scripts to show the size change on build:

create-react-app/packages/react-dev-utils/FileSizeReporter.js

Lines 34 to 35 in d0afe4b

	var fileContents = fs.readFileSync(path.join(root, asset.name));
	var size = gzipSize(fileContents);

[audiolion]

thanks for the reply, my mistake, I thought that just gzipping it wouldn't give the same results as webpack's uglify + gzip, but of course the build is already minified.

on a fun side-note, that reporter file is utilizing the webpack stats file :)

create-react-app/packages/react-dev-utils/FileSizeReporter.js

Line 28 in d0afe4b

var assets = (webpackStats.stats || [webpackStats])