[Feature] Max size/request control over chunk splitting to avoid mass network requests in core scenarios

[dzearing]

We're evaluating the esbuild output in a few apps here at Microsoft. We tried bundling a particular app which consists of approximately 25 async imports. Using splitting, about 70 chunk files were added to the initial load. Some of the chunks are as small as 70 bytes. We need some way to mitigate the extra network traffic due to chunking.

Webpack's SplitChunksPlugin has a lot of control over how the common chunks are grouped together, which helps to avoid excessive download situations. You can get into scenarios where you may end up downloading more code than needed, but fewer overall network requests. If we were able to essentially feed esbuild a list of routes to optimize around and it prioritized fewer requests for those routes, that would be pretty slick. That might even enable some scenarios where routes shift based on usage and as such we can pipe in usage data and rebundle periodically.

We were thinking maybe this could be done as a post process job on the output given the meta file. Essentially concatenate the primary entry-point chunks and fix references, source-maps, etc. But would not want to do this work if better control were around the corner.

There might be an issue already open here; I know https://github.com/evanw/esbuild/issues/16 is still open because splitting is a WIP.

I've seen similar concerns in https://github.com/evanw/esbuild/issues/399 and maybe https://github.com/evanw/esbuild/issues/207 and https://github.com/evanw/esbuild/issues/268. Just couldn't find anything specific to adding some optimization tuning around chunk output to emit less files.

[evanw]

Code splitting is still a work in progress, and doesn't fully work yet (as you are aware, since you linked to #399 and other issues). I'm mainly prioritizing work on code splitting correctness over other features right now. The linking algorithm is in the process of being rewritten and the current linker will be thrown out, so it's not the right time to start tuning things. I'm aware of the desire for manual chunk labels and I plan for the rewrite to make this possible.

[dzearing]

Thanks for your hard work @evanw. Correctness is best to prioritize. We are referencing this bug to let teams know this area is stabilizing.

[arcanis]

Almost half of the 1400+ chunks generated by esbuild in our application are less than 1kb. Being able to set a minimal size would be crucial to avoid page load regressions.

[joker-777]

@evanw This comments was made more than a year ago. Have you been able to work on this?

[arobinson]

Unfortunately this is a blocking issue for us with esbuild. We dynamically (on demand) generate and build code after the initial bundling of our software on an as needed basis. We need reliable file (chunk) names as a result between builds. Unfortunately there are no APIs to control what chunks files being created and with what contents. Without this level of control we have either post-process the files (combining the chunks back into one file and live without source maps produced by esbuild) or use another bundling tool

[MarcCelani-at]

This is impacting us as well. When we test out esbuild in production, it introduces very sizable performance regressions. Is there no super hacky, warranty voiding way of tweaking the number of chunks or min chunk size? I have to imagine something is hard coded somewhere that we could change.

[joker-777]

I wish there would be a solution. For us, this is the only thing that is blocking us from using esbuild. It seems to be actively maintained and improved but code-splitting isn't part of it although it is on their "high priority" list :(

[mohamedmansour]

tunately this is a blocking issue for us with esbuild. We dynamically (on demand) generate and build code after the initial bundling of our software on an as needed basis. We need reliable file (chunk) names as a result between builds. Unfortunately there are no APIs to control what chunks files being created and with what contents. Without this level of control we have either post-process the files (combining the chunks back into one file and live without source maps produced by esbuild) or use another bundling tool

You can run look into the Build Metadata: https://esbuild.github.io/api/#build-metadata to see what chunks are for which entry point. With that information, you can do what you want.

[MicroDroid]

Why is #3302 not merged?

[dimeloper]

Since we also need this, may I ask why #3302 is not merged yet? Is there maybe an alternative way of setting the minimum chunk size?