menu
announcement

Spectrum will become read-only on August 10, 2021. Learn more about the decision in our official announcement.

React

A community of developers, designers and others who love React.js. ⚛️

Channels
Team

How to handle deployments with webpack code splitting ?

April 29, 2018 at 6:30pm

How to handle deployments with webpack code splitting ?

April 29, 2018 at 6:30pm
Here's an unexpected issue I've run into with Webpack code splitting in the wild:
Imagine this scenario:
The user loads a React app with Webpack code splitting and a few bundle chunks are loaded
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)
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?
Note: The problem description is copied from Stack Overflow as the author clearly describes the issue better than me.

April 29, 2018 at 7:26pm
Blue green deploys implemented properly are what you want to aim for. As well having a checksum for the bundle chunks will aid in making the code splitting more robust. Does that help?
  • reply
  • like
ServiceWorkers come in really handy when doing code splitting!
We use the excellent offline-plugin by 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! 💯
like-fill
9
  • reply
  • like

April 30, 2018 at 9:08pm
ServiceWorkers come in really handy when doing code splitting!
We use the excellent offline-plugin by 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! 💯
oh wow! this is a super handy library!
like-fill
1
  • reply
  • like
The old school solution for this problem, btw, would be to store all the files of previous versions and have them uniquely named, e.g. with a hash in the name.
  • reply
  • like
Another solution might be to make every chunk know the current version. So if if new one is being loaded, it checks for the version and if it doesn't match -- it simply reloads the page. Same for chunks which are missing, you reload the page when network error happens
  • reply
  • like
But yeah, offline-plugin solution is much nicer 😀 just wanted to throw some other possible solutions here
  • reply
  • like

January 7, 2020 at 10:32am
but for service worker: User need to close all tabs or fully close the browser to see the changes reflected. A page reload will not reflect the changes.
  • reply
  • like
We were planning to show modal asking user to refresh page, but when a user has multiple tabs opened.. it will eventually show modal for all pages ... and even if he just refreshes each of those.. Im not sure if it would be running on new or old version please suggest
Edited
  • reply
  • like