Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dzearing opened this issue Apr 8, 2021 · 9 comments

Comments

@dzearing
Copy link

dzearing commented Apr 8, 2021

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 #16 is still open because splitting is a WIP.

I've seen similar concerns in #399 and maybe #207 and #268. Just couldn't find anything specific to adding some optimization tuning around chunk output to emit less files.

@evanw
Copy link
Owner

evanw commented Apr 9, 2021

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
Copy link
Author

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
Copy link

arcanis commented Feb 1, 2022

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
Copy link

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

@arobinson
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

Why is #3302 not merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants