webpack
allow to use non-eager shared and remote modules in the initial page load
- bundle will become async to load the required remotes and chunks
- fix a bug with circular remote module loading
- fix duplicate remote and shared runtime module when using plugin multiple times
What kind of change does this PR introduce? feature, bugfix
Did you add tests for your changes? yes
Does this PR introduce a breaking change? no. This caused an error before.
What needs to be documented once your changes are merged? Using shared modules in initial chunks is now possible, but this will delay bootstraping of the application until all remotes and the shared modules are loaded. For performance reasons this should be avoided if possible.
Currently the performance is lacking behind what's possible: (need to be improved in further PRs)
- Shared and remote modules are loaded sequencially instead of in parallel
- When using a single runtime chunk, all remote and shared modules for all entrypoints are loaded.
For maintainers only:
- [x] This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
- [ ] This needs to be backported to webpack 4 (issue will be created when merged)
works on example repos, but errors out on something like a next.js build.
https://github.com/ScriptedAlchemy/nextv5
Looks like it might not cater for multiple entrypoints?
This resolves most cases IMO, with requiring import(bootstrap) no longer a most
I do see some edge cases / challenges with entry point loaders where multiple entry points are used over a code splitting. (Next.js)
Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon.
@sokra in order to make this work with multi-entrypoints.
Would we need to add some startup requirements to single entry points we well? In cases where runtimeChunk: single exists, when the chunk is pushed into webpack, we would need a form of startup module. Correct?