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(chunk): Introduce asyncChunkMode and default to 'eager' #8645
base: main
Are you sure you want to change the base?
Conversation
For maintainers only:
|
My only obvious concern is that this will make it harder to catch CORS misconfigurations; but fixing CORS is a one-time thing, this build loop happens several times per hour... |
@TheLarkInn Could you update the test configurations to keep the old behavior? |
For some real-world data from Outlook Web's codebase, I ran both v5-alpha.6 and this branch in dev watch mode 5 times each, and triggered 5 incremental builds for each run.
|
@ooflorent what do you think is the best approach here. Should I set mode |
@TheLarkInn I think the existing tests should use |
The basic integration tests succeeded, but the full suite failed. @TheLarkInn Please review the following output log for errors:
Show remaining errors
See complete report here. |
@ooflorent did fixing initial errors find more errors? lol |
So I will have to approach this PR different. Reaons:
Alternative:
thoughts? |
This change is an incredible win for build performance on our project. Even if it's purely opt-in, I'm really looking forward to it. |
@TheLarkInn can't we have for now it opt-in only? Or "if is wasm go lazy", being realistic we don't use wasm but the performance boost that we get in that is huge |
If you want to solve this on development right now on webpack 4 try this patch-package https://gist.github.com/sibelius/baf12454c371e9d6c728376c39d9f1e0 I do recommend to only apply the patch on development, not sure about production builds effects this will break hot reload, but it will rebuild faster |
Fixes #8644
What kind of change does this PR introduce?
Feature
Did you add tests for your changes?
Not yet, but we'll get there.
Does this PR introduce a breaking change?
Yes.
Technically this is a breaking change. By default webpack generates in
mode: development
a individual bundle for each use ofimport()
. This PR would modify this behavior for the users dev environment to not create additional async bundles.However functionally this may only cause break's on extreme edge cases (strange SSR/mode usages?).
What needs to be documented once your changes are merged?
Addition of a new configuration property
"eager" is the default for development environment, and "lazy" is the default for any other mode.