How to handle deploys with Webpack code splitting?

Question

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

Answer 1

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!

https://github.com/NekR/offline-plugin

This solution means your app downloads all the chunks up front, which defeats the purpose of code splitting in terms of bandwidth, but at least you still retain the benefit of only parsing the chunks you need to load the app, which for me is significant on slow devices. Also, browser refreshes/caching now involves the Service Worker lifecycle (see "Waiting" at https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle).

Answer 2

This problem is extremely well stated.

I will add though that "Deletion" might not be the right name for whats happening, depending on the setup.

My initial response to this problem was that this was a caching problem. That old chunk files were being picked up instead of the new one. Its close to what was happening at least in my case I had the following:

index.js

const Page1 = lazy(() => import('./page/Page1'));
const Page2 = lazy(() => import('./page/Page2'));

const main = () => {
  {
    '/page1': Page1,
    '/page2': Page2,
  }[window.location.href](); /* Some Render Router Implementation */
};

1. V1 Deployed at (https://my-domain/distribution_folder/*)
2. User would load V1 index.js
3. V2 Deployed at (https://my-domain/distribution_folder/*)
4. User (who hadn't refreshed) would dynamically load a chunked route using their cached V1 index.js file.
5. Request would be sent to (https://my-domain/distribution_folder/{page_name}.{chunk_hash}.js)
6. A chunk error would occur because that unique chunk would no longer be there.

Its interesting because the provider that was being used was migrating traffic to the new version. So I thought that would be the end of it but what I wasn't realizing was that any user could still be using a previously deployed version - How would they know? They're already using the application. The browser already downloaded the application (index.js).

The solution really depends on where you're dynamically importing these chunks. In the case above since they're page routes we can do a hard refresh when the user requests a different page when we can't find a chunk. This assumes however that your Cache-Control headers are setup correctly though. For example:

• index.js -> Cache-Control: no-store
• page/{page_name}.{chunk_hash}.js -> Cache-Control: public,max-age=31536000,immutable

We can make these chunks immutable because sometimes they don't change between releases and if they don't change why not use the cached version. However, index.js cannot be stored in the cache because this is the "router" that dynamically loads the content and this will always change.

Pros

• No more chunk load errors
• We don't need to load everything on first page load
• Less complexity by not having a service worker

Cons

• This approach forces a refresh for users

Related Questions

• Webpack Code Splitting 'Loading chunk failed' error wrong file path
• Angular 2 Error: Loading chunk failed many times
• Webpack - Loading chunk 0 failed
• ChunkLoadError: Loading chunk XY failed. - Randomly getting fatal on PRODUCTION

Answer 3

if the chunk filenames are hashed, wouldn't old route link to old hashed chunk (which presumably would still be available) and load everything fine?

Answer 4

https://webpack.js.org/guides/caching/#output-filenames

A simple way to ensure the browser picks up changed files is by using output.filename substitutions. The [hash] substitution can be used to include a build-specific hash in the filename, however it's even better to use the [chunkhash] substitution which includes a chunk-specific hash in the filename.