Case against enabling `AutomaticCommonsChunksPlugin` in webpack by default
See original GitHub issueIs this a bug report?
No. This is a discussion of the changes recently introduced by the AutomaticCommonsChunksPlugin
webpack plugin, that is now enabled by default in CRA v2. The issue is that the vendor chunk produced for our application is approaching 100KB in size, which seems to defeat the purpose of using dynamic imports for code splitting.
Here are the chunks we get in CRA v2.0.0-next.66cc7a90 without the new plugin enabled:
File sizes after gzip:
73.97 KB (-55.31 KB) build/static/js/main.d1abdfcb.js
48.3 KB build/static/js/LandingPage.f0ddef0e.chunk.js
16.42 KB build/static/js/Calendar.e70e80b4.chunk.js
9.18 KB build/static/js/CarClassPage.cc65304c.chunk.js
2.35 KB build/static/js/NotFoundPage.40cd51b8.chunk.js
1.51 KB build/static/js/FullScreenModal.a1abcd70.chunk.js
1.15 KB (-5.37 KB) build/static/css/main.3287133e.css
482 B build/static/js/CityPage.f084c178.chunk.js
Here are the chunks we get in CRA v2.0.0-next.a671462c:
91.78 KB build/static/js/vendors.65bb2654.chunk.js
16.41 KB (-31.9 KB) build/static/js/LandingPage.60fe2b8b.chunk.js
8 KB (-65.97 KB) build/static/js/main.b62c6c3c.chunk.js
3.84 KB (-5.34 KB) build/static/js/CarClassPage.57a04e32.chunk.js
3.29 KB build/static/css/vendors.470d376f.chunk.css
2.06 KB build/static/css/LandingPage.c6f351b7.chunk.css
1.36 KB build/static/js/runtime~main.5afc2beb.js
1.1 KB (-417 B) build/static/js/FullScreenModal.a7d8d07f.chunk.js
1.09 KB (-63 B) build/static/css/main.5bd1cab6.chunk.css
1.09 KB build/static/css/CarClassPage.2ea1f4b6.chunk.css
466 B (-16 B) build/static/js/CityPage.67cf514e.chunk.js
444 B (-1.92 KB) build/static/js/NotFoundPage.a1daedf0.chunk.js
102 B build/static/css/FullScreenModal.e95a181c.chunk.css
Our concern is that the size of the vendor chunk will continue to grow as we add more third party components to our application, and with this plugin enabled by default, we will be unable to customize the code splitting effectively.
Proposed solutions
- Disable
AutomaticCommonsChunksPlugin
or make it opt-in - Use some kind of heuristic to produce more than one vendor chunk, for example by optionally generating a vendor chunk for each user-defined dynamic import that includes third party code
Related PRs/issues
Issue Analytics
- State:
- Created 5 years ago
- Comments:8 (4 by maintainers)
Top Results From Across the Web
CommonsChunkPlugin - webpack
The CommonsChunkPlugin is an opt-in feature that creates a separate file (known as a chunk), consisting of common modules shared between multiple entry ......
Read more >Webpack 4 migration CommonsChunkPlugin - Stack Overflow
Webpack 4 now by default does optimizations automatically. It analyzes your dependency graph and creates optimal bundles (output), based on the following ...
Read more >webpack 4.0.0-alpha.5 feedback · Issue #6357 - GitHub
NamedModulesPlugin -> optimization.namedModules (on by default in develoment mode). [new] CommonsChunkPlugin was removed -> optimization.
Read more >High-performance webpack config for front-end delivery
CommonsChunkPlugin is now enabled, and knows to use the vendor entry point as the base for the CommonsChunk. You may have seen a...
Read more >webpack 4: released today!! . Codename: Legato - Medium
We have deprecated and removed CommonsChunkPlugin, and have replaced it with a set of defaults and easily overridable API called optimization.splitChunks. Now ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Always producing a single vendor file should not be a default. Even after doing code splitting still, vendor bundle will be having all code(vendor)
I’m not arguing against it - I had a hard time trying to figure out sane defaults when I made the webpack 4 pr. Just open a pr and argue for the case.