-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
feat(splitting): support minChunkSize option #3302
base: main
Are you sure you want to change the base?
feat(splitting): support minChunkSize option #3302
Conversation
b956b4b
to
a6fa07c
Compare
a6fa07c
to
8851bd5
Compare
@evanw This would be really high-impact for my team, as I believe that chunk size is the only thing preventing us from switching from Rollup to esbuild. You mentioned that you intended to eventually rework the linker to support more customizable chunking behavior -- would you be open to merging this solution as a stopgap for now? |
I tried to locally compile this and test it with out project, however, the result is not working. After enabling the minChunkSize some of the imports are no longer working. In my case the require_prop_types is not defined. |
@fochlac Can you provide a minimal reproducible use case? |
Is there any update to this? or any better solution? |
@ArrayZoneYour I tried to set up a smaller case back then, but never got it to work. Our codebase is pretty large and we originally had ~1k small chunks. My assumption when seeing the issues was that some imports chains were not properly resolved after the first iteration of merging chunks together. The missing imports appeared only in sections that were merged into other files. For our project we stopped pursuing solving this directly in esbuild and instead I setup a custom plugin to create manually defined chunks with our larger dependencies and disabled code-splitting alltogether. I'll attach the plugin here, but tbh. it feels hacky and has quite a few caveats. i.e. it can bloat individual bundles if dependencies are missing, it's weak to circular dependencies, and does a lot of manual parsing. Also there is no documentation besides a little jsdoc. And it's really bad at handling deep library imports (from 'lodash/get'). It has tests, though. ^^'' It would propably be possible to clean this up and make it a proper library, but we plan to remove this complexity from our build chain and solve it via switching to https2 or using a service worker to handle the larger bundles via background downloads before they are actually required. |
fix #2901, #2419, related to #207
When there are many entry points, it is easy to generate some small chunks.
This MR try to land minChunkSize options to control the chunk size by source content size