ESBUILD code splitting is way worse than webpack #26622
Comments
|
missing ES Build output |
|
LIbrary config files: |
|
Managed to replicate it. |
|
Archive.zip 
And i think it will pack seAction only with "feature-cars" chunk with webpack as far as it is used only inside this lazy loaded component. |
|
It is probably more important as far as developers (us included) use this type of codesplitting for things like:
Icons are used as an example, because they are super primitive (just svg constants) |
|
@alan-agius4 just one small piece of information. You have provided an example with 2 constants inside 1 file. We were not able to make them split into multiple smaller chunks and had to split them to multile TS files. It was tip by @kreuzerk as he mentions here: Maybe webpack cannot split 1 file to multiple chunks (A file is miminal piece of data that can stand alone?) So it will be nice, if esbuild is able to be better :-) |
|
I guess your answer is hidden here evanw/esbuild#2636 (comment) And the short term solution would be, don't use barrels. They slow down your entire toolchain anyway (build, ide, typescript). Especially the If you used a generator to generate the barrel, you may create an index.ts with |
|
??? Dont use barel? just diffent name. In our case, we have only 1 index.ts file generated by NX monorepo as entry poinnt to library / secondary-entry-point library. 
|
|
I'm not saying you are wrong. Just saying that there are workarounds. And omitting barrels is not as ridiculous as it seems. After all it's the same move angular recently did with the switch from NgModule (kinda like a manual managed barrel) to standalone (direct import) |
|
Even though barrel files might occasionally trigger tree-shaking bailouts, it's inconsequential here since the code resides within a library where all files are bundled into a single FESM file. The capability for file splitting in esbuild has been removed according to this commit: evanw/esbuild@fad7f47. I've raised an issue here: evanw/esbuild#3531 for it to be re-added. In this scenario, the recommended approach is to export each icon as a separate entry point, mirroring the way @angular/material exports its components. As it stands, there's no action we can take on our part regarding this matter until it has been addressed upstream. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Command
build
Is this a regression?
The previous version in which this bug was not present was
Angular 16/17 - Webpack build
Description
We have medium size application which is developed with code splitting in mind.
For the instance:
STATS file with @angular-devkit/build-angular:browser:
stats.json.zip
As you can see - as an example, icons are "spread" across almost all lazy-loade chunks + 1 chunk with "widespread" icons:
68kB stat size.
But with ESBuild - stats file:
esbuild-stats.json
As you can see, all icons are packed together to 1 single chunk - and it has 190kb
Difference?
Webpack:
ESBuild:
Way we import the icons:
Index file + structur:
Minimal Reproduction
= in Webpack, ConstantA will land only in LazyChunkRouteA, LazyChunkRouteB etc.
= in ESBuild, All constants will be in standalone lazy loaded chunk...
Exception or Error
No response
Your Environment
Anything else relevant?
Latest NX monorepo, full standalone, buildable library, secondary entry points
The text was updated successfully, but these errors were encountered: