You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
0 commit comments