A registered service worker breaks development

[Timer]

If you happen to run serve -s build and it installs a localhost service worker, all future development is borked (no page reloading).

We need to fix this problem... do we need to add something like this?

if (process.env.NODE_ENV === 'development') {
  navigator.serviceWorker.getRegistrations().then(function(registrations) {
    for (let registration of registrations) {
      registration.unregister()
    }
  })
}

I believe the docs mention this, but it's super annoying.

/cc @jeffposnick

[gaearon]

I can’t seem to reproduce this so far.

[gaearon]

Ah, @Timer says he uses 5000 as DEV port (which is default PROD port).
I guess it’s not very common that people would use the same port but we should probably avoid that.

[Timer]

Having export PORT=9000 in .bash_profile probably has the same effect. 😄

Will send a PR.

[jeffposnick]

Unwanted service workers taking control due to sharing ports between environments can definitely be an issue. It's really a good idea not to mix ports across environments if at all possible, but obviously developers might do that.

The problem with writing conditional code that refers to process.env.NODE_ENV and unregistering based on that is that the process.env.NODE_ENV is converted into a real string and inlined into the HTML, which then will get read directly from the cache by the service worker. So in the scenario you describe, the same process.env.NODE_ENV value (i.e. 'production') will be reused.

The best way of dealing with this would be to create a no-op service worker that will be checked in to the development source, and that would be overwritten by the production service worker when a build is done.

This no-op service worker will end up being fetched from the development web server in the scenario you describe, and then the next visit to the development page will behave as if there were no service worker present.

I'm happy to file a PR for this after confirming that there are no unexpected side effects locally.