fix: call stats.toJson on each time to avoid the stats mutation

[wood1986]

fix #292. But I need some help about testing these change.

[jsf-clabot]

All committers have signed the CLA.

[mistic]

LGTM

[wood1986]

Hey @valscion and @th0r Do you have any updates?

[th0r]

I'm a little worried about performance and memory aspect of this change as stats object can be huge. Is it possible to better find problematic places (which modify original stats object) and fix them instead?

[wood1986]

I'm a little worried about performance and memory aspect of this change as stats object can be huge. Is it possible to better find problematic places (which modify original stats object) and fix them instead?

1. I will not prefer this because it is not scale-able. Every time you introduce a new state mutation and you will need to undo it somewhere. Additionally, because of the Promise.all you modify the same object and it will still have a chance to break others.

2. Currently, if people need the correct stat.json and there is a bug which will affect them when it is generated from this plugin, they will choose to re-run webpack with --json. The time of the re-run must be more than the performance that you are concerned.

3. The plugin will only run a maximum of 2 tasks which are generateStatsFile and either startAnalyzerServer or generateStaticReport. Not sure how many people need 2 tasks and I do not think there are a lot. Here is the test from my app and my stats.json is about 50.4MB. I do not think 160.253 is a lot.

generateStatsFile: 160.253ms // stats.options = {}
generateStaticReport: 905.879ms

generateStatsFile: 13.481ms // stats.options = { children: false, chunks: false, modules: false, sources: false, reasons: false }
generateStaticReport: 964.424ms

[th0r]

1. I will not prefer this because it is not scale-able. Every time you introduce a new state mutation and you will need to undo it somewhere. Additionally, because of the Promise.all you modify the same object and it will still have a chance to break others.

What I'm talking about is find places that modify original stats object and rewrite them because it's a bug - they shouldn't do this.

2. Currently, if people need the correct stat.json and there is a bug which will affect them when it is generated from this plugin, they will choose to re-run webpack with --json. The time of the re-run must be more than the performance that you are concerned.

I'm sorry I don't quite follow.

3. I do not think 160.253 is a lot.

Where is this number came from? What are those logs about? Is first log represents your approach and the second one is the current implementation? Why does stats options differ then?

[wood1986]

What I'm talking about is find places that modify original stats object and rewrite them because it's a bug - they shouldn't do this.

If you are still talking about one stats object does everything, I do not think I cannot because

webpack-bundle-analyzer/src/BundleAnalyzerPlugin.js

Line 38 in 44bd8d0

stats = stats.toJson(this.opts.statsOptions);

. If I pass the trimmed stats to startAnalyzerServer or generateStaticReport, it cannot show the chunk details and it will only be a rectangle box with the name. I believe this is not expected result.

Here is the scenario I need, I want the plugin output the report with the chunk details. At the same time, I want the plugin output the stat.json which will remove some fields that the report need.

I'm sorry I don't quite follow.

What I am trying to say is this is the workaround that I am using to achieve the scenario I mentioned right before that. And I have to pay more to wait for the output. The performance and memory that you are concerned are not a lot. They are 160.253ms and 51MB of RAM

Where is this number came from? What are those logs about? Is first log represents your approach and the second one is the current implementation? Why does stats options differ then?

Both logs is after my fix.

160.253 comes from the statsOptions = {} in the worst case scenario which outputs everything. The first log is about when you specify statsOptions = {} you have to pay another 160.253ms to output the stats.json. If you apply the filter in statsOptions, you have to pay 13.481ms to output the stats.json.

[th0r]

Ok, I finally understood what the problem is. Apologize for my dullness 😉

[th0r]

Published in v3.4.0

[dosentmatter]

Just a note for anyone who sees this. I am using nextjs and I was trying to generate stats with webpack-bundle-analyzer, but I kept getting truncated JSON. As in JSON that just ends randomly and is invalid. I didn't try version 3.4.0 but 3.4.1 fixed it for me. I'm guessing 3.4.0 would have worked too because it had this fix.