Unclear default code splitting in cra v2

[slava-lu]

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 (#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 webpack/webpack#7968

[roneesh]

@ianschmitz, thanks so much for your informative answer! I really appreciate it and all that the CRA team does for the community.

My only question is how reliable is the chunking you've laid out? If If I don't use dynamic imports in my application at all, can I consistently expect those three files to be made, and with those names?

Ideally I'd like to opt of code splitting, but if I can't, then as long as the file names remain consistent I can whip up some scripts to copy the files over to my .net project. But if the names are volatile then I'd have to constantly update my build process.

Please let me know, and if you need a PR for docs I'm happy to help.

Thanks!

[keshavmesta]

@ianschmitz thanks for the elaborative info! Exactly what I was looking for. I think it makes sense to add it to code-splitting ?

[bflatmajor]

@ianschmitz Why is my 1.[hash].chunk.js different even I don't change anything from node_modules?

[ianschmitz]

I've created #5900 to help try to clear things up in our docs.