How should we update workbox?

[oliviertassinari]

Library Affected:
workbox-build

Browser & Platform:
all browsers

Issue or Feature Request Description:
This is a generic question around the upgrade strategy for workbox. We were using v3.0.0-beta.0 on Material-UI. Two weeks ago, we decided to upgrade to the latest version (v3.6.3) to keep up with the latest changes. However, the upgrade hasn't gone smoothly. Many people raised issues following the release of the upgrade:

• Most (not all) Click Event not working on https://material-ui.com website on firefox browser mui/material-ui#13560
• official doc site, left side menu does not work in Safari 12.0 mui/material-ui#13530
• Safari Service Worker Problems mui/material-ui#13373
• [docs] Service worker issue after workbox update mui/material-ui#13422
• https://material-ui.com/ menu not working in Firefox mui/material-ui#13461
• https://material-ui.com/demos mui/material-ui#13462

So, I'm wondering. What's the “safe" way to update workbox? Thank you.

[jeffposnick]

First off, apologies that you and your users ran into issues.

In general, updating Workbox from minor/patch release to minor/patch release is meant to be backwards compatible, and nothing specific should be necessary other than rebuilding and redeploying.

Looking at your service worker, it seems that you're precaching a complete, versioned copy of all your sites resources. (Which is fine!) In the interval between v3.0.0-beta.0 and the current v3.6.3, there were a couple of updates made to the precaching logic that might have had a positive impact:

• Fallback to fetch() if the precached response is missing. #1302
• Precaching temp #1342

Additionally, I took a peak at your build process, and found the following scripts:

"docs:build": "cross-env NODE_ENV=production BABEL_ENV=docs-production next build",
"docs:start": "next start",
"docs:export": "next export -o docs/export && yarn docs:build-sw && cp -r docs/static/. docs/export",
"docs:size-why": "DOCS_STATS_ENABLED=true yarn docs:build",
"docs:build-sw": "babel-node ./docs/scripts/buildServiceWorker.js",
"docs:deploy": "git push material-ui-docs master:latest",

It looks like docs:export is what's responsible for running docs:build-sw, but I don't see what triggers docs:export. Are you sure that your code to generate your service worker is run prior to each deployment of your docs to your production web site—are there are deployment paths in which it might not be run? Deploying updates to your versioned assets without also updating the service worker would definitely be a problem.

[oliviertassinari]

In general, updating Workbox from minor/patch release to minor/patch release is meant to be backwards compatible, and nothing specific should be necessary other than rebuilding and redeploying.

@jeffposnick Ok, great! We will keep up with the latest changes from time to time then :). Hopefully, it will go smoothly next time.

but I don't see what triggers docs:export.

We have configured Netlify to ran the command:

The logs are public, you can find the latest here.

[jeffposnick]

Thanks for passing along that Netlify logging output—it does seem like the service worker generation is being run at the correct time.

If your users do encounter any of these issues now that you've updated out of the older v3.0.0-beta.0 release, please do let us know—I am hopeful that they won't recur.

[chyvak1831]

@oliviertassinari I'm curious about workbox and issues what your users had with caching: so, best solution was to add self.skipWaiting() - right?
I'm asking because I want to add workbox to my regular WP (unique URLs) projects, but it seems that I can break projects when update in future if not use self.skipWaiting()...

[oliviertassinari]

@chyvak1831 TL;DR using precaching without as skip activation logic for a service worker is worse that not using any service work. Never do it.

We have changed the approach, the solution is way more scalable now:

• [docs] Improve the service-worker logic mui/material-ui#13987 (introduce a skip waiting logic to for the activation of the service worker once installed)
• [docs] Reduce by /50 the website traffic mui/material-ui#14122 (use a cache first logic with a hard reload to force the control of the page when a new service working is installed)