Disable service worker by default

[iansu]

Addresses disabling service worker by default from #2554.

[iansu]

Importing both of these results in a lint error because only one of them is ever used. We could override eslint for this line, we could only import one and update the comment below (ugh) or we could do something else entirely like only using registerServiceWorker and passing it a boolean to enable/disable.

[gaearon]

How about using * import?

import * as serviceWorker from './serviceWorker';

// ...
serviceWorker.unregister();

[iansu]

Good suggestion Dan. I'll make that change.

[iansu]

If I use the * import and don't change registerServiceWorker.js the call to registerServiceWorker() has to be registerServiceWorker.default() which is kind of gross.

Is it okay to change registerServiceWorker.js?

[zyzski]

I'd say registerServiceWorker could use some edits, at least in the comments to tell the dev it's opt-in and how that opt-in works.

What about adding a new function in registerServiceWorker.js to help devs destroy a service worker if their users are stuck with it by mistake? AFAIK .unregister() doesn't execute unless the rendered service-worker.js has changed.

Was looking at adding something like this to my own rSW.js

[gaearon]

@iansu I'm proposing to make both functions named exports.

[jeffposnick]

Thanks for taking this on, @iansu!

As it's currently implemented, unregister() is

export function unregister() {
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker.ready.then(registration => {
      registration.unregister();
    });
  }
}

navigator.serviceWorker.ready is a promise that will resolve whenever there's an active service worker whose scope includes the current URL. Assuming that there is an active service worker, that promise will resolve consistently on each page load. There is no requirement that the service worker file has actually changed in order for it to resolve.

I touched some of the code in registerServiceWorker.js initially, and am happy for folks to make changes as long as the general logic remains consistent.

[petetnt]

The default export still needs to be registerServiceWorker too though (even if both are named exports too) for it to be backwards compatible (even if this lands to a major version update 2.0.0, it would be unneccessary to break everyones build for such a tiny change).

Still partial to passing the boolean in myself: #2554 (comment)

[gaearon]

It won't break anyone's build because this part is copied into every project. Even if we changed completely the API between them, we could've shipped that in any patch release IMO.

[iansu]

Thanks for the feedback everyone. I think I've addressed it all.

[gaearon]

People reading this probably don't know what service worker is.
Can you rewrite this so it's a bit less wordy, and also understandable to most folks?

[iansu]

Now that's a challenge! 😀

I guess we can remove the first sentence and maybe link to that Google page from the docs about what a service worker is. Alternatively we could just link to the "Making a Progressive Web App" section of the CRA docs. I'll work on it.

[gaearon]

I was thinking something like

// If you want your app to work offline and load faster, you can change “disable” below to “enable”.
// Note this comes with some deployment pitfalls.
// Learn more about service workers: <...>

[jeffposnick]

If it helps, https://developers.google.com/web/fundamentals/primers/service-workers/ attempts to be a one-stop landing page for a service worker overview, and https://developers.google.com/web/progressive-web-apps/ is a similar landing page for PWAs in general.

[iansu]

I've updated the comments about using Service Worker in index.js. Currently the link points to the "Making a Progressive Web App" section of the CRA docs.

[piotr-cz]

Note that is in comment (If you want your app to work offline and load faster...)
should go to /README.md and packages/react-scripts/template/README.md#making-a-progressive-web-app as well

[gaearon]

Yep, we’ll update the docs before the release.
#3864

[quantumproducer]

+1 for this. Deployed to an HTTP site and my script is erroring because of service worker

[ghost]

Any idea when this will be released? Nobody removes it where I work and then it causes all sorts of problems in staging that the senior devs have to fix. It also causes problems in development since every new app defaults to localhost:3000 and the service worker will be serving up old artifacts for that address. Actually, during development the times that it caused problems was when we were not using localhost, but an actual domain.

[bugzpodder]

This will be released as part of 2.0 release. Note that this only affects the new app template, that means if an app was already bootstrapped with service worker, upgrade to 2.0 will not have any impact. If you have an existing worker that makes uses of service workers in production, you'll have to manually clean it up by unregistering.