When using AMD output, use AMD for code-split chunks as well
See original GitHub issueDo you want to request a feature or report a bug?
A new feature that would improve code-splitting with externals.
What is the current behavior?
Context : An application which is build with multiple sub-applications which are each built with Webpack, and the “orchestration” of loading all this is done through requirejs. One of the things with this platform, is that react is provided through requirejs so that each plugin can reuse a single global library instead of re-loading it for each app. (Any other library could be provided globally, I use react as the example here) /context
When we generate a library in amd with some externals and code-splitting. The thing is that externals are defined only at the main level even though it’s the code-split part that need those externals.
Example :
// main.min.js
define(['react'], function(a) { /* Doesn't actually need react yet */ });
// 1.main.min.js
webpackJsonp([0],{3: function() { /* actually needs react */});
Wouldn’t it be better if it was able to generate it this way ?
// main.min.js
define(function() { /* Doesn't actually need react yet */ });
// 1.main.min.js
define(["react"], function(a) {
return {
chunkIds: [0],
moreModules: {3: function() { /* actually needs react */}}
}
});
Advantages are :
- no custom logic to load modules, requirejs knows how to do it.
- external dependencies are loaded when they’re actually needed
- no need to specify a name for the jsonp function as it’s done through requirejs
Problem with the current implementation:
- externals might be loaded too early, which defeats the purpose of code splitting and lazy loading of those parts.
If the current behavior is a bug, please provide the steps to reproduce.
It isn’t a bug, just the normal behaviour that could be more optimal
What is the expected behavior?
To load externals once they are needed
If this is a feature request, what is motivation or use case for changing the behavior?
My motivation is that I have an application that supports plugins, each of those can be implemented with any techology, React, jquery, vanilla js … while they mostly use React today, we don’t know what the future holds for us. Which is why we want to be able to lazily load libraries once they are actually used.
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
We use webpack 3.5.2
Issue Analytics
- State:
- Created 6 years ago
- Reactions:29
- Comments:24 (2 by maintainers)
This feature request would be useful, for example, to develop Grafana plugins. Grafana uses SystemJS (which is compatible with AMD) to load plugins. So, if I want to use Webpack to package a set of Grafana plugins (such as a Grafana App plugin), I need to have multiple entry points (one for each plugin), all of them in the AMD format (so that SystemJS can load them). But if they have common dependencies, I don’t want them to be duplicated in each entry point bundle… but if I use a common chunk, SystemJS currently does not know about it and will not wait for this chunk to be loaded before executing the loaded plugin. But if Webpack created this chunk in the AMD format and used AMD to load it, SystemJS would correctly wait for it to be loaded before executing the plugin that depends on it.
We are in the middle of migrating a requirejs-based application with custom bundling to a React SPA with webpack4. With AMD output we could load the split chunks through our old loader, too. That would make it incredibly more convenient to create a commons package holding our third party dependencies, while keeping our old module system in place until we are finished. So this would make webpack much more appealing to people coming from another loader.
Right now the only solution for us is to use one fat bundle for React/3rdParty and lose all advantages of dedicated bundling, unless we switch to webpack as loader (which is no option atm).