Unclear default code splitting in cra v2
See original GitHub issueIs this a bug report?
If very unclear documentation is a bug then yes.
A newly created and built app with Create react app v2
creates three js chucks by default. But there is not a single line in neither index.js nor in App.js that does code splitting according to this guide
https://reactjs.org/docs/code-splitting.html
I could not find any info, not in release notes, nor anywhere else why there are three bundles now without any dynamic import statements, what is the point and benefits of having three bundles even for 120K app, and what to do if I want only one js but want to keep other features of cra v2.
There is a ticket to disable a code splitting (https://github.com/facebook/create-react-app/issues/5306) but could you please elaborate a bit why it there in the default app in the first place if neither line of code asks for that.
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (2 by maintainers)
Sure i can help try to explain @slava-lu.
You’re correct there are 3
.js
chunks generated in a build of a freshly created CRA app without using any dynamic imports. We use webpack internally and leverage mostly default config from SplitChunksPlugin to do the code splitting for us. For reference there is some great info about webpack 4 code splitting in an article written by the creator of webpack here: https://medium.com/webpack/webpack-4-code-splitting-chunk-graph-and-the-splitchunks-optimization-be739a861366main.[hash].chunk.js
App.tsx
, etc.1.[hash].chunk.js
cacheGroups
), which includes modules you’ve imported from withinnode_modules
.runtime~main.[hash].js
index.html
by default (saves a request). You can opt out of this by specifyingINLINE_RUNTIME_CHUNK=false
as documented in our advanced configuration, which will then load this file instead.One of the potential advantages with splitting your vendor and application code, is that you can use long term caching techniques to separate your vendor code and cache it for an extended period of time (1 year for example). The idea is that your vendor code is usually less volatile than your application code, which means if you push new versions of your app out without adding/updating your dependencies, your users should only have to download an updated copy of your application code, making your app load faster.
I highly recommend you add a
Cache-Control: max-age=31536000
or similar to assets being served from thestatic
folder, as all the files in this folder will have a hash name appended to the file name, and thus are safe to cache for an extend period, and give your users the best performance. Yourindex.html
should have aCache-Control: no-cache
to ensure your users get an updated page when you update your app. Check out Google’s http caching guide for more info.Hope this clears things up. I agree that we can do a better job explaining things in our code splitting docs. Let me know if this info was helpful and perhaps I can expand on it a bit in our docs.
Thanks for the info. It was really helpful. But I think it would be very useful to be able to opt out of code splitting. The main reason is the library development rather then an app. If the outcome of your project is js bundle, not the index.html with js you may have some pain with loading the chunks. More info in my other ticket here https://github.com/webpack/webpack/issues/7968