Something that drives me bonkers about current tree shaking is that there’s no good way to see what got shaken.
I want a graph that shows me all the branches that got culled.
Even better would be a dependency graph that shows me what is causing things not to be culled.
I had an issue where Antd was pulling in 200KB of icons and I couldn’t figure out why until I spent hours bisecting it by commenting out entire sections of my application.
Something that drives me bonkers about current tree shaking is that there’s no good way to see what got shaken.
On a super basic level you can just build with and without tree-shaking and diff the results. If you turn off transpiling and minification, and move your bundled NPM modules to their own separate file, you can see what parts of your own code got shaken out pretty easily.
I'm tempted to have a go at writing a tool to do that actually. It would be useful.
It doesn't have to be perfect, from static analsis you can get what people want. It won't cover dynamically created keys but people don't use it anyway. You'd just have to provide list of entrypoints and ie. vscode plugin could gray out or put horizontal grey bar for code that's shaken. It would be great plugin.
A solution would need to be fast an incremental. Also we have got much faster bundlers with tree-shaking support recently (for example esbuild and parcel adopting swc), fast incremental correct builds seems to be still not completely there. E.g. cache invalidation would need to be correct in all possible cases, which does not seem to be the case yet, according to some Github issues I read recently.
Otherwise I agree such a tool in VS would be great. Not that if you generate sourcemaps you kind of have a similar view in Chrome. Shouldn't therefore not be too difficult to implement in principle for VS.
Interesting thing to notice is that for vscode plugin it probably doesn't have to be fast/incremental – the reason is that you want to skip node_modules completely (minus symlinked) - because it's for code you're developing, not full blown tree shaking on final bundle that has to visit everything.
Comments
Something that drives me bonkers about current tree shaking is that there’s no good way to see what got shaken.
I want a graph that shows me all the branches that got culled.
Even better would be a dependency graph that shows me what is causing things not to be culled.
I had an issue where Antd was pulling in 200KB of icons and I couldn’t figure out why until I spent hours bisecting it by commenting out entire sections of my application.
Something that drives me bonkers about current tree shaking is that there’s no good way to see what got shaken.
On a super basic level you can just build with and without tree-shaking and diff the results. If you turn off transpiling and minification, and move your bundled NPM modules to their own separate file, you can see what parts of your own code got shaken out pretty easily.
I'm tempted to have a go at writing a tool to do that actually. It would be useful.
diffs (and network graphs) seem like a great idea, but they quickly get so big that one can't make heads or tails of the visualization.
It would actually be quite amazing if dead code analysis of branches are integrated into eslint or other linters.
But yeah, I guess that would also require a VM like understanding of timeouts, intervals and the Browser's triggered events so it's kinda hard to do.
It doesn't have to be perfect, from static analsis you can get what people want. It won't cover dynamically created keys but people don't use it anyway. You'd just have to provide list of entrypoints and ie. vscode plugin could gray out or put horizontal grey bar for code that's shaken. It would be great plugin.
A solution would need to be fast an incremental. Also we have got much faster bundlers with tree-shaking support recently (for example esbuild and parcel adopting swc), fast incremental correct builds seems to be still not completely there. E.g. cache invalidation would need to be correct in all possible cases, which does not seem to be the case yet, according to some Github issues I read recently. Otherwise I agree such a tool in VS would be great. Not that if you generate sourcemaps you kind of have a similar view in Chrome. Shouldn't therefore not be too difficult to implement in principle for VS.
Interesting thing to notice is that for vscode plugin it probably doesn't have to be fast/incremental – the reason is that you want to skip node_modules completely (minus symlinked) - because it's for code you're developing, not full blown tree shaking on final bundle that has to visit everything.