webpack-bundle-analyzer

webpack-bundle-analyzer copied to clipboard

only support js bundle ?

What do you want to see inside a CSS chunk?

just like the js chunk I guess. the size, the dependencies. don't know whether it's doable.

Yeah, I also expected to see all assets that webpack emits, so fonts, images, css, html, js. That way I can get a sense of size and dependencies for all of these things.

If someone wants to take a stab at this, it would help a lot. Even a small sample repository using CSS assets / fonts / images what have you would be nice, as then we could discuss how would an output for such a project look like.

@valscion I've been looking into this and would like to see if I can help on this. I've spent the day understanding how this plugin works + interacts with webpack.

I'll start working on a sample repo with multiple asset inclusion. I assume the plan would be to use that to generate a webpack stats file to write tests for?

I've been looking into this and would like to see if I can help on this.

Thanks!

I'll start working on a sample repo with multiple asset inclusion.

Sounds great :+1:

I assume the plan would be to use that to generate a webpack stats file to write tests for?

I'm not sure how we will end up using the sample repository yet. Writing tests might not be enough, as we will also want to figure out how we'd like the output to be displayed in the generated treemap. So it might need some design iteration first before we write tests

After a bit more investigation I think we can split this up into 2 problems:

1. Singular assets (e.g. images, fonts)
2. Concatenated assets (e.g. css, js)

The first problem only requires us to find which src asset was turned into which output asset. From there it could be displayed in the visualiser in the correct chunk(s).

The second problem requires us to have this mapping for each file. For JS this is done by creating an AST from the output asset, and reverse engineering the webpack bundling process. This won't be possible for styles as they're just concatenated, and this won't let us know where they came from.

I agree this needs more design before we move forward, but I'll continue to make a helper-repo that bundles assets in different ways.

---

I've got a couple ideas of how to solve these:

1. Singular
   • We can still make progress on images / fonts
   • We can treat css as a single asset (it won't say where it came from, but better than nothing?)
2. Concatenated
   • We could offer this if people provide source maps?
   • We'd be able to find out exactly what src styles end up in the css assets
   • This might work for js too?
   • This would mean re-writing all the parsing internals 😰

Would be interesting to see how the output will look like once you get the helper repo in place :relaxed:

I'm not sure if the concatenated version would require re-writing all parsing internals ☺️ we already do support concatenated modules, but it just might need some additional work to work for CSS, too

any news about this amazing feature? ☺️

Quick repo here that builds scripts, images and styles.

(This has index.css importing a.css and b.css)

This shows the size of the css asset created, but doesn't show the src files inside, and this suggested feature would solve that.

I think I used 'concatenate' badly in the previous comment, and didn't mean concatenated modules. I was trying to say that the output .js files leave behind how webpack bundled them. But with css they're just concatenated and there isn't a way to tell where they came from (that I know of)

I would love to see a chunked view of my app.css

I have over 140 scss files and some of them look deceivingly simple but include a while loops so at a glance they don't look that large.

It would also help me to reduce redundant CSS being served.

@iambalaam If you don't use MiniCssExtractPlugin, a.css and b.css will show in all.js

@yuxizhe is that CSS extracted from Javascript or processed from SCSS?

@adampatterson I think its less-loader | scss-loader that causes the problem. I will look into these loaders and find out why.

• only use css-loader

• use css-loader and less-loader

---

maybe webpack Module Dependencies explains why:

https://webpack.js.org/contribute/writing-a-loader#module-dependencies

In the case of the less-loader, it cannot transform each @import to a require because all .less files must be compiled in one pass for variables and mixin tracking. Therefore, the less-loader extends the less compiler with custom path resolving logic. It then takes advantage of the second approach, this.resolve, to resolve the dependency through webpack.

less-loader or sass-loader transform @import to this.resolve instead of require，maybe webpack can't work out the relationship between style files without require

bump, i dunno if anyone still cares, just throwing out there that I would find this useful for analyzing a large project full of nested scss imports. in case anyone has found any workarounds, or other tools that might be useful.

@yuxizhe's tip about disabling MiniCssExtractPlugin was helpful to get me part of the way there, but it's still a black box in terms of how relative size breaks down within the nested imports beyond the top-level entry point

guess i can just use file sizes for now, but it's not really the full picture once compiled

FWIW, my use case is trying to identify common-sense places to split a monolithic sass file into split output files, but as some end up being really small, it doesn't necessarily make sense to split all by page-type or whatever the face-value approach would be.

being able to analyze the contributions of each import to the final compiled output would help very easily visually identify these logical split points

for now i basically just have to split everything, and then work backwards in terms of re-merging files that are so small that it doesn't make sense for them to be independent.

I think analyzing CSS code splitting might be a bit out of scope of this plugin — how CSS is handled can differ so much compared to how JS is handled that the additional maintenance burden on supporting CSS might prove to be too much.

I'd be happy to be proven otherwise — if support for CSS analysis can be done in an easy-to-maintain way that can also be optional, I might change my mind.

There is also the matter of purge CSS which is more common now. I don't know if that would be an issue but when I first interacted with this thread I wasn't using it.

I am also looking for such a function. My project has a really large CSS bundle size and I don't which module to optimize.