Unclear default code splitting in cra v2

Is 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.

[ianschmitz]

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-be739a861366

main.[hash].chunk.js

• This is your application code. App.tsx, etc.

1.[hash].chunk.js

• This is your vendor code (example webpack config can be seen here under cacheGroups), which includes modules you’ve imported from within node_modules.

runtime~main.[hash].js

• This a small chunk of webpack runtime logic which is used to load and run your code. The contents of this will be embedded in your index.html by default (saves a request). You can opt out of this by specifying INLINE_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 the static 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. Your index.html should have a Cache-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.

[slava-lu]

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