-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PWA / Service worker breaking production deployments #2440
Comments
Additionally, you can not remove the service worker because if you try to unregister in a new deploy, the user will never see the updated bundle. |
cc @jeffposnick |
Looks like something to do with "now". Works for me - Checked with "surge" and localhost |
cc @rauchg |
Thank you @bunshar ! I tried Deployed same app on No idea what happened or what I did different. Happy to close this and assume I managed to screw something up multiple times and over-react. I will keep an eye on my projects and see if I can narrow down what happened. |
Still running into issues on firebase. Deploying same newly create app to
Will see if its working tomorrow and will contact firebase and see what they say. |
Just to prove I am not crazy and this is a thing on firebase. Deploying changes with |
Let’s keep it open and wait for @jeffposnick to help with diagnosing this. |
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 It's unfortunately a common pain point, since many hosting providers will default to a medium-length cache lifetime for assets like The service worker specification was changed to cause HTTP caching of 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. |
cc'ing @davideast from Firebase as an FYI regarding the current cache-control max-age above. Jeff's summary is quite accurate but it would be good to get a check-in on the medium-length lifetime for static assets. Checking back in on #2441, it appears this is now only an issue for Firebase hosted content vs other hosts.
I'm going to chase trying to get some resource behind working on this internally. |
For those who come across this issue, here is how you should be able to fix it for Firebase Hosting. Edit your {
"hosting": {
"headers": [
{ "source":"/service-worker.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}] }
]
}
} |
Thanks @mbleigh, it works! {
"hosting": {
"headers": [
{ "source":"/service-worker.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}] }
]
}
} |
Thanks, I updated my snippet to match yours. That's what I get for assuming I remember all of my product's config from the top of my head. 🤦♂️ |
@jeffposnick - Thanks for clearing things up. That makes a lot more sense. I had index.html cache-control set to 0 but all .js files are set to 3600 on the test cw-app and 7200 on my production app. Because you know, cache busting. @mbleigh @antmarot - That configuration works great for firebase. Thanks. Does this mean that In terms of those steps in the Offline-First Considerations. Force-refresh (and having no-cache on) doesn't seem to fix the issue, maybe Chrome doesn't refresh the service worker? Looks like maybe it's a Chrome issue? In fact, I can see chrome saying that @addyosmani - Is this deliberate? (Meaning developers need to check 'update on reload' option in Chrome to force no-cache?) Can also confirm was not working in Firefox 52 but is now working in Firefox 54. |
Yes,
The best practice is to keep the service worker file name constant (i.e. Including a hash in the file name means that you couldn't serve the file that contains the Keeping the file name consistent, and relying on the service worker update flow to handle cache updates, means that you can serve all your static content cache-first. But it also means that if your |
Thanks for the through explanation @jeffposnick, very useful info. |
Thanks for the help! 👍 It's very frustrating to find this solution, as I didn't even know about the existence of service workers. (Which is actually pretty cool that it's bundled so good into CRA). Please add it to the docs to the |
Closing in favor of #2398. |
Hi everyone, sorry for asking a similar question in a closed issue, thought it is related to it and the solution might be simple. I am trying to set cache header for sw with nginx, in the configuration like it has been done in firebase, I tried
However when I load my page, sw registration fails with the message.
@gaearon @Timer @jeffposnick @addyosmani @mbleigh Can someone please help me with this? |
facebook/create-react-app#2440 This should resolve an issue where `index.html` is cached and pointing at an invalid JavaScript bundle.
Is anybody still experiencing this issue? I've just created an app via create-react-app and deployed it to Firebase but when I check the Network and Application tabs in dev tools the service worker isn't there? When I do a local serve -s build it runs perfectly, but it doesn't appear to be loaded through Firebase. Doing a Lighthouse audit it says there is no service worker on the page, yet inside the build dir the service-worker.js is there and it's also inside the asset-manifest.json. Thanks all! |
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
npm run build
cd build
deploy firebase
Check website
Can someone else confirm this is affecting them?
I am hoping I am doing something wrong and this isn't affecting every production deploy.
The text was updated successfully, but these errors were encountered: