PWA / Service worker breaking production deployments

EDIT: Issue appears to be with Firebase only

Service workers aren’t refreshing index.html and therefore new deploys are showing old bundles.

This means production websites or really all deployed sites that use a single url/domain can not be updated.

PR #2441 - Is a hotfix (if needed) that just removes the service worker and updates docs to say they have been disabled temporarily.

@gaearon @timer @jeffposnick @addyosmani

Steps to reproduce

• create-react-app sw-test
• cd sw-test
• npm install
• npm run build
• cd build

Deploy with firebase

• firebase deploy
• Visit site https://[project].firebaseapp.com. Confirm working.
• Change app.js
• npm run build
• cd build
• deploy firebase

Check website

• Visit site again and no changes shown. DevTools shows SW is providing index.html and old bundles.
• Force refresh a few times. No difference.
• Delete service worker.
• Refresh.
• See correctly updated site.

Can someone else confirm this is affecting them?

I am hoping I am doing something wrong and this isn’t affecting every production deploy.

[mbleigh]

For those who come across this issue, here is how you should be able to fix it for Firebase Hosting. Edit your firebase.json and add headers like so:

{
  "hosting": {
    "headers": [
      { "source":"/service-worker.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}] }
    ]
  }
}

[jeffposnick]

What you’re running into with https://cra-sw.firebaseapp.com/ is described in item 5 of the “Offline-First Considerations”, and is due to service-worker.js being served with HTTP caching headers.

It’s unfortunately a common pain point, since many hosting providers will default to a medium-length cache lifetime for assets like .js files. Updating your web app’s assets relies on detecting an updating service-worker.js file, and that is complicated when the browser’s cache comes into play. (The cache headers are always ignored if the file is over 24 hours old; it there’s more historical detail here.)

The service worker specification was changed to cause HTTP caching of service-worker.js to only happen when a developer explicitly opts-in, and Firefox has already implemented that change in FF53+.

Chrome has unfortunately not caught up, and still honors the HTTP caching headers. I was just asking about the status of this internally yesterday, and I’ll point the relevant folks to these discussions, given the larger audience that is likely to inadvertently run into this.