Open 0xdevalias opened 4 months ago
Even more tangentially related to this, I've pondered how much we could 're-construct' the files necessary to use tools like bundle analyzer, without having access to the original source (or if there would even be any benefit to trying to do so):
Webpack plugin and CLI utility that represents bundle content as convenient interactive zoomable treemap
You can analyze an existing bundle if you have a webpack stats JSON file.
You can generate it using
BundleAnalyzerPlugin
withgenerateStatsFile
option set totrue
or with this simple command:webpack --profile --json > stats.json
Stats Data When compiling source code with webpack, users can generate a JSON file containing statistics about modules. These statistics can be used to analyze an application's dependency graph as well as to optimize compilation speed.
My gut feel is that we probably can figure out most of what we need for it; we probably just can't give accurate sizes for the original pre-minified code, etc; and the module names/etc might not be mappable to their originals unless we have module identification type features (see https://github.com/pionxzh/wakaru/issues/41)
You want a re-constructed stat.json
or records.json
which can be put back into an analyzer plugin, right? This can be useful to understand the shape and code size distribution in chunks.
I just did some research on it. I feel it's possible to generate stats.json
, but it requires deep understanding about the bundling details of webpack. And the module graph would be a must for us to do this.
This is the sample that I get on google. https://gist.github.com/TheLarkInn/577d6a8896b4553d4b2865fe1c8db7fa
You want a re-constructed
stat.json
orrecords.json
which can be put back into an analyzer plugin, right?
@pionxzh nods yeah, that was what I was originally thinking about; and then I was thinking that there might also be some crossover with the parts used for this that could align with figuring how to identify module changes/etc.
Here's another search that should pull up a bunch more samples:
This is an idea I've had in passing a few times, but keep forgetting to document it:
I'm not 100% sure if this would be useful, or partially useful, but I think I am thinking of it tangentially in relation to things like: