Here's an unexpected issue I've run into with Webpack code splitting in the wild: Imagine this scenario:

1. The user loads a React app with Webpack code splitting and a few bundle chunks are loaded
2. A deploy happens and the contents of any future chunks that the user might receive from the server are updated (note: the previous chunks get deleted on the server during a deploy)
3. The user clicks on a link and loads a new route which triggers more bundle chunks to load. Except these new chunks are incompatible with the ones the user's browser has already loaded and the app breaks because of a runtime error

How can this scenario be prevented?

One possible solution would be to maintain multiple versioned sets of chunks but I'm wondering if there's a simpler solution being used by large-scale apps.

If preload-webpack-plugin is used, all chunks can be prefetched but they will only stay cached for a short time (5 minutes in Chrome).

Here's an unexpected issue I've run into with Webpack code splitting in the wild: Imagine this scenario:

1. The user loads a React app with Webpack code splitting and a few bundle chunks are loaded
2. A deploy happens and the contents of any future chunks that the user might receive from the server are updated (note: the previous chunks get deleted on the server during a deploy)
3. The user clicks on a link and loads a new route which triggers more bundle chunks to load. Except these new chunks are incompatible with the ones the user's browser has already loaded and the app breaks because of a runtime error

How can this scenario be prevented?

One possible solution would be to maintain multiple versioned sets of chunks but I'm wondering if there's a simpler solution being used by large-scale apps.

If preload-webpack-plugin is used, all chunks can be prefetched but they will only stay cached for a short time (5 minutes in Chrome).

• javascript
• reactjs
• deployment
• webpack
• code-splitting

• 1 I'm having the same considerations as yours. Do you find a solution? Thank you! – Jordan Enev Commented Feb 26, 2018 at 10:27
• 1 @JordanEnev we ended up maintaining multiple versions of deploys so that the old chunks wouldn't get invalidated. – Maros Commented Feb 26, 2018 at 18:55
• Thank you! If I find something simpler, I'll write. – Jordan Enev Commented Feb 26, 2018 at 20:58
• 2 Interested in a solution for this. Would it be possible to have the webpack loader code respond with some sort of alert that would ask a user to reload? – james Commented Jan 23, 2019 at 13:22
• 1 Just simple solution, we can use push via websocket after deploy, and show the notification that page should be reloaded window.navigation.reload() or use long polling and check the latest version from somewhere, for example, from latest index.html – BILL Commented Sep 3, 2020 at 14:41

4 Answers 4

As Max Stoiber writes on spectrum.chat:

ServiceWorkers come in really handy when doing code splitting!

We use the excellent offline-plugin by @nekr to cache all the current bundles locally, so no matter if the server updates the files or not the ServiceWorker will always serve the files from the local cache. Every hour it will check the server for updates and, if an update is available, download all the fresh bundles from the remote server and cache them locally. The next time the user restarts the app the new version of the app is used!