This repository has been archived by the owner on Jan 23, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 388
cache index.html for offline, but refresh on new deploy #356
Comments
Hm 🦆 , is it perhaps possible to avoid the issue by not using hashes in the bundles? That |
Update, the issue has a fix, but I don't think the underlying issue is resolved. Here is how we force a reload of the service worker when new content is detected: (It's a workaround at best)
|
manuelkiessling
added a commit
to manuelkiessling/nodebeginner.org
that referenced
this issue
Sep 17, 2018
…blem. The problem was as follows: - Webpack builds the app js and stores it as e.g. app.hash-1.js - When requesting the server, the client initializes the service worker, which in turn stores /sw-precache-appshell in the cache; in sw-precache-appshell's HTML, app.hash-1.js is referenced; also app.hash-1.js is stored in the cache - On subsequent soft-loads, the content of sw-precache-appshell is served from the cache - The app is changed and rebuilt, resulting in file app.hash-2.js; file app.hash-1.js is no longer served by the backend - Another soft-load results in the cached version of sw-precache-appshell being served, which still references app.hash-1.js - as this is still in the cache and served from there, all works fine - The service worker fetches itself at /service-worker.js, realizes that the app js has changed, fetches app.hash-2.js, and stores that in the cache, removing app.hash-1.js from the cache; however, the service worker does not realize that /sw-precache-appshell changes, which could be a bug in sw-prefetch; thus the "old" version of sw-precache-appshell which still refers to the "old" app.hash-1.js, remains in the cache - Doing a soft-load again, the service worker serves the old sw-precache-appshell content, where app.hash-1.js is now referenced; as this is available neither from cache nor from the backend, the app stops working The solution here is to NOT use any kind of hash-based file naming for WebPack-generated files, but simply use a static name; this way, the reference is always to "app.js" which always matches, while the service- worker still knows when to fetch new file content and update the cache. See GoogleChromeLabs/sw-precache#356 See api-platform/website#62 See gatsbyjs/gatsby#4636 See GoogleChromeLabs/sw-precache#269 (comment)
manuelkiessling
added a commit
to manuelkiessling/nodebeginner.org
that referenced
this issue
Sep 17, 2018
…blem. The problem was as follows: - Webpack builds the app js and stores it as e.g. app.hash-1.js - When requesting the server, the client initializes the service worker, which in turn stores /sw-precache-appshell in the cache; in sw-precache-appshell's HTML, app.hash-1.js is referenced; also app.hash-1.js is stored in the cache - On subsequent soft-loads, the content of sw-precache-appshell is served from the cache - The app is changed and rebuilt, resulting in file app.hash-2.js; file app.hash-1.js is no longer served by the backend - Another soft-load results in the cached version of sw-precache-appshell being served, which still references app.hash-1.js - as this is still in the cache and served from there, all works fine - The service worker fetches itself at /service-worker.js, realizes that the app js has changed, fetches app.hash-2.js, and stores that in the cache, removing app.hash-1.js from the cache; however, the service worker does not realize that /sw-precache-appshell changes, which could be a bug in sw-prefetch; thus the "old" version of sw-precache-appshell which still refers to the "old" app.hash-1.js, remains in the cache - Doing a soft-load again, the service worker serves the old sw-precache-appshell content, where app.hash-1.js is now referenced; as this is available neither from cache nor from the backend, the app stops working The solution here is to NOT use any kind of hash-based file naming for WebPack-generated files, but simply use a static name; this way, the reference is always to "app.js" which always matches, while the service- worker still knows when to fetch new file content and update the cache. See GoogleChromeLabs/sw-precache#356 See api-platform/website#62 See gatsbyjs/gatsby#4636 See GoogleChromeLabs/sw-precache#269 (comment)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I am currently using the sw-precache-webpack-plugin with this config: (yes, another project, this is just to show the config, since some of the configuration options are passed to
sw-precache
+sw-toolbox
). This is a SPA.We initialize the service worker like this in an attempt to always load the new service worker when we deploy:
Operation-wise, it works as intended. But, we cache
index.html
for offline usage, and this also caches the reference for the app file,app.<__webpack_hash__>.js
, leading to the wrong bundles being requested.Scenario (from clean slate):
/index.html
app.fd9e432.js
is loaded/project-sw.js?build=fd9e432
.. next visit after redeploy (new hash):
/index.html
(which is cached by the previous service worker)app.fd9e432.js
is loaded (same as last time)/project-sw.js?build=fd9e432
/newpath
, webpack tries to load bundle with old hash:newpath.fd9e432.js
and gets a 404The cache headers on
index.html
andproject-sw.js
is the same (no cache):Is there a configuration I am missing here, or what am I doing wrong?
The text was updated successfully, but these errors were encountered: