After #171 is merged, this plugin will be able to bundle multi-page apps for production. It's currently using the default splitChunks config however, which means that libraries/frameworks used by multiple entry points will be bundled into each entry chunk separately (e.g. if you navigate to /home then /blog on a site that requires React, you may end up downloading React twice).
For multi-page applications, it could be really helpful to use a granular chunking strategy by default, similar to Next.js and Gatsby. These are the heuristics that Next uses to reduce duplication across chunks:
Any sufficiently large third-party module (greater than 160 KB) is split into its own individual chunk
A separate frameworks chunk is created for framework dependencies (react, react-dom, and so on)
As many shared chunks as needed are created (up to 25)
The minimum size for a chunk to be generated is changed to 20 KB
I'm currently able to implement this in my own applications by extending the default Webpack config with args.extendConfig, but maybe this is worth making a default? Perhaps only for builds with multiple entry points?
After #171 is merged, this plugin will be able to bundle multi-page apps for production. It's currently using the default splitChunks config however, which means that libraries/frameworks used by multiple entry points will be bundled into each entry chunk separately (e.g. if you navigate to
/homethen/blogon a site that requires React, you may end up downloading React twice).For multi-page applications, it could be really helpful to use a granular chunking strategy by default, similar to Next.js and Gatsby. These are the heuristics that Next uses to reduce duplication across chunks:
I'm currently able to implement this in my own applications by extending the default Webpack config with
args.extendConfig, but maybe this is worth making a default? Perhaps only for builds with multiple entry points?