You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Reacted by Marvin Heilemann, yhyykysj, Alisa Sireneva, Ryan Bates, Vít Stanislav, Ryan Mahan, Polar stoat, Robert and Axel Kennedal
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 👍
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:
Singular assets (e.g. images, fonts)
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:
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?)
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 ☺️
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
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)
Reacted by Iván Rodríguez, Chiawen Chen, Mark Brand, Xizhe Yu, Guy Balaam, Alejandro Corredor, Ranieri Benvenuto, Yuliia and Herz3h
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.
Activity
th0r commentedon Jun 4, 2018
What do you want to see inside a CSS chunk?
lili21 commentedon Jun 4, 2018
just like the js chunk I guess. the size, the dependencies. don't know whether it's doable.
ccarse commentedon Nov 29, 2018
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.
valscion commentedon Nov 29, 2018
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.
iambalaam commentedon Dec 8, 2018
@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?
valscion commentedon Dec 11, 2018
Thanks!
Sounds great 👍
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
iambalaam commentedon Dec 11, 2018
After a bit more investigation I think we can split this up into 2 problems:
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:
valscion commentedon Dec 11, 2018
Would be interesting to see how the output will look like once you get the helper repo in place☺️
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
NarHakobyan commentedon Dec 25, 2018
iambalaam commentedon Jan 4, 2019
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
.jsfiles 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)adampatterson commentedon Apr 23, 2019
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.
yuxizhe commentedon Jun 13, 2019
@iambalaam If you don't use
MiniCssExtractPlugin, a.css and b.css will show in all.jsadampatterson commentedon Jun 13, 2019
@yuxizhe is that CSS extracted from Javascript or processed from SCSS?
yuxizhe commentedon Jun 14, 2019
@adampatterson I think its
less-loader|scss-loaderthat causes the problem. I will look into these loaders and find out why.maybe webpack
Module Dependenciesexplains why:less-loader or sass-loader transform
@importtothis.resolveinstead ofrequire，maybe webpack can't work out the relationship between style files withoutrequirejakedowns commentedon Dec 11, 2020
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.
valscion commentedon Dec 11, 2020
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.
adampatterson commentedon Dec 11, 2020
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.
guoyunhe commentedon Mar 25, 2022
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.