Repository navigation
Unregister service worker #2715
Description
Just wondering what the easiest way is to unregister the existing cra service worker once already deployed. I am on "react-scripts": "1.0.7". I'd be happy to provide more info if that makes it clearer what version of CRA I'm using.
The README includes this passage
"If you had previously enabled service workers in your production deployment and have decided that you would like to disable them for all your existing users, you can swap out the call to serviceWorkerRegistration.register() in src/index.js with a call to serviceWorkerRegistration.unregister(). After the user visits a page that has serviceWorkerRegistration.unregister(), the service worker will be uninstalled."
I don't quite understand what I need to change in the src/index.js file to unregister the sw. I have tried importing the unregister func, and running that with no success. I apologize in advance if what I'm missing is very obvious.
As a side note, I see the value in the service worker and think adding in as part of CRA was a great move. For this particular use case however, I need my updates seen immediately. Thanks!
Activity
gaearon commentedon Jul 3, 2017
This should work. How did you verify that it doesn't?
louisnovick commentedon Jul 3, 2017
I checked the deployed site, with unregister() added just as you've outlined, on other computers which had the SW. I will verify.
gaearon commentedon Jul 3, 2017
cc @jeffposnick
gaearon commentedon Jul 3, 2017
(As I understand, since the worker is already cached, it will take at most 24 hours for changes to take effect. Once they get the new bundle within this period, everything should be fine.)
jeffposnick commentedon Jul 5, 2017
Indeed, taking out the call in
index.jsthat registers your service worker will prevent new registrations, and add inwill cause an existing service worker to unregister.
If you happen to have HTTP caching set up for your deployed
service-worker.jsfile, then it might take up to 24 hours (depending on your cache lifetime) for the changes you've deployed to be picked up by existing clients.If you're seeing unexpected behavior, please let us know.
louisnovick commentedon Jul 6, 2017
Thank you for the responses. The next time I need to unregister the worker I'll do what you've instructed knowing that it may take some time (24hrs). If I know a deployment will need to be seen right away I will remove the service worker well in advance.
gaearon commentedon Jul 7, 2017
The delay shouldn't happen if service worker isn't cached. So you can avoid it if the server is configured not to HTTP cache the service worker.
Clarify registering and unregistering service workers in README.md
corysimmons commentedon Mar 4, 2018
Is there a way to just delete registerServiceWorker.js and still compile?
bportman commentedon May 30, 2018
Hello, I am trying to unregister the service worker on an app that was created in February, and it does not have registerServiceWorker.js at all - is there a way for me to recreate it so I can unregister it? Or does it's non-existence indicate that my app is not registering a service worker at all?
bugzpodder commentedon May 30, 2018
Normally I would say that your app is probably not registering service workers, but to be 100% sure you'd have to look at the git history to see when service worker was taken out (and just bring that code back).
Since you haven't been running service workers for a while so I would say it's okay to just leave it as is unless you have some known issue.
bportman commentedon May 31, 2018
Thanks @bugzpodder - it turned out the problem I was trying to solve had nothing to do with the service worker and related to mixing multiple versions of the material-ui library. That said, I did verify in my git repo that the file never previously existed.
rei-gun commentedon Jun 7, 2018
I just unregistered my service worker and it is still showing however I am concerned that my service worker may NEVER die because it does not have Cache-Control set at all (see attachment)! Will is still die eventually?
I'm also concerned about this promise error I'm seeing in Chrome's console (see attachment).
Tremus commentedon Jun 20, 2018
Eject your settings, go to your
webpack.config.prod.jsremove the importrequire("sw-precache-webpack-plugin")on around line 10, remove the instance of the plugin from around line 340, then service worker will never be built.rei-gun commentedon Jun 20, 2018
@Tremus I don't even have
webpack.config.prod.jsin my repoTremus commentedon Jun 20, 2018
@double-reinbows
Have you ran
npm run eject? (NOTE: irreversible)Another possible solution (not recommended, but a solution nevertheless) is to use this:
source - https://stackoverflow.com/questions/33704791/how-do-i-uninstall-a-service-worker
BowersMatthew commentedon Jul 20, 2018
I am seeing a similar issue to the OP. I have deployed with a service worker. My client reported that updates to the site were not showing up. On investigation I found that some clients were seeing content which is 3-4 updates behind (over a month old). I attempted to remove the service worker using the method from the readme and in this thread. The result is that new visitors get new content, because the service worker is not registering at all, but clients who previously visited the site are never getting new content served. Clearly if the customer visits the site via one of the other domain names they get new content and it is great, but there is no way to communicate this out to clients, nor can I reach into their dev tools and unregister the offending sw.
I have attempted clearing the cache on my personal laptop which has the broken service worker. Now when I load the site the console shows:
The script has an unsupported MIME type ('text/plain').
Failed to load resource: net::ERR_INSECURE_RESPONSE
Prior to clearing the cache and adding the call to unregister an additional error reported that the sw failed to register then the sw served the stale content.
I understand that this is likely due to an interaction with react-router and I have removed the offending wildcard route. But, since the computers in question never see new versions of the main.js this only prevents future problems with resolving the current mess.
The error message about the sw failing to register stopped appearing when I changed the call to unregister. So it seems like the browser is reacting to the changes to index.js but it is failing to unregister the worker. As an experiment I add some logging so the unregister function now says:
export function unregister() { console.log('attempting to remove this sites broken service worker'); if ('serviceWorker' in navigator) { navigator.serviceWorker.ready.then(registration => { registration.unregister(); console.log('removing sw'); }); };If I visit the site from a browser without the old service worker I get the first message but not the second as expected. A browser with the old service worker does not show either.
The network tab show a fetch to this index.html returns with status 301 from disk cache which is reasonable since I have cleaned the cache but then the sw kicks in and starts serving the old content from cache.
It has been 2 days since changing the call from register to unregister so any cached pages should have expired.
I am very much at a loss of what to do next. I am almost a week into investigating this and my clients customers are potentially stuck with a stale website. We did change the link on google to route to the www. version of the web address so anyone who gets to the site via google rather than direct navigation will get the new sw free version of the site, but I am concerned about those who have set up bookmarks or like me rely on autocomplete in the navigation bar.
Reading (w3c/ServiceWorker#614) it seems like there are some ideas of adding a kill switch for just this kind of situation but I am not seeing where anything has been implemented.
jeffposnick commentedon Jul 23, 2018
Service workers will not unregister/deactive if they're removed from the remote server. (See w3c/ServiceWorker#204 for a detailed discussion.)
Following the steps outlined in https://stackoverflow.com/questions/33986976/how-can-i-remove-a-buggy-service-worker-or-implement-a-kill-switch to deploy a "no-op" service worker is the best course of action for the scenario you describe.