-
Notifications
You must be signed in to change notification settings - Fork 803
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
Unexpected token < error after redeploy (InjectManifest Mode) #2053
Comments
It sounds like you're running into described in this section of the docs:
Can you make sure that you're not unconditionally calling |
Hey @jeffposnick , thanks for the resources, I've gone through them and looks like "refreshing" is a complicated thing to do.
We are using vue-cli3-pwa-plugin and this is the boilerplate kind of thing for registration code.
This is an approach that is suggested by workbox too. But it just breaks my app when I reload the page after a new service worker is activated, since it tries to find an old cached html file that is not updated well in sw activation phase. The app breaks because it still uses an old html file from the cache that has links to old js files that can't be found anymore. In another case, I just deleted the code for skipWaiting and tried to activate new sw after closing all the tabs and opening in new tab. While activation has been successful, after a page reload it's still fetching the old html file and js files that do not exist anymore. Can you explain me the order of these events for a bug free pwa while using workbox webpack plugin:
This is what I understood about the life cycle, correct me if I'm wrong I would love to understand it better. But I would be glad if you could help me know why my app is using old html file after a page refresh while sw has been activated correctly. Also, my issue is more related to #1528 and looks like it is solved in workboxV4. But I'm using vue-cli-pwa-plugin which also has workbox-webpack-plugin as dependency. While I'm trying to update the pwa-plugin to latest 3.7.0 which possibly has updated workboxv4, it is still showing me workbox-3.6.3 in package-lock.json. Thanks |
It's possible that your service worker is still waiting to activate after the update is found and even after you refresh. Sometimes refreshing the page won't skip the waiting phase if there are other tasks pending or other clients still open. You could try using |
Hey @philipwalton && @jeffposnick I have tested it thoroughly and I don't have any issues with service worker activation, It works very fine, I send a refresh prompt while new sw is in waiting phase and on accepting it, it skips waiting and gets activated, I even tested it by closing all tabs and reopening to get it activated and I can see all that happening correctly in dev tools. There is no issue I see with how my service worker is activating, it works great. but the problem could have been during the cache cleanup phase, something is wrong with it. Also I see that there is precache-manifest-temp along with pecache-manifest cache in cache API which could be messing up things while I'm still unsure about it.
If I add code to delete caches in registration phase like this:
only then does it fetch my new html and app.js files otherwise if it's normal like this
it always tries to fetch old files. But I don't want to delete caches everytime during registration, this just means my caching is useless. Our app is in production already and redeploying has become a nightmare for us. Deleting the caches in registration is the only hack I found so far to not break the app while redeploying. May be you can help me understand why it works fine after I delete previous caches, I have no idea about it. Please help me know what I'm doing wrong here. I would like you to take a look at #1803 #1528 #1783 I find them very much similar to this but I don't see any solution to them as well. Please help A few other similar to this: |
I am on v4 and facing similar issue (there are no temp caches). Have tried following (as suggested remedies), but to no avail:-
All my hashed cache files use StaleWhileRevalidate strategy. Wondering if the cause of this issue could be a conflict between the strategy (staleWhileRevalidate) I am using and the way Workbox handles cache refresh? I could try NetworkFirst, but that'll go against my app's preferred behaviour. Seconding @sourybunny - deleting old caches on register is also not a solution. Ensuring smooth redeployments is absolutely critical for a PWA to compete with Native apps. Arguably, native apps have improved a lot when it comes to managing user experience during app updates. I really think there has to be a better, more straightforward way to deal with this issue. The default doesn't seem to be working for me. |
@sharanan-sarvsutra |
Just clarifying a gap in my understanding of workbox caching - I am using CRA (create react app)'s build tool that auto-hashes the build files. Unlike precached files, it seems files cached via a strategy (such as StaleWhileRevalidate) require manual refresh when modified. Workbox's waiting event callback seems like a good place to do this. Couldn't find a plugin to avoid doing this from scratch. A few observations:-
Interestingly, I am no longer getting the 'Unexpected token <' error because workbox is able to handle updates to the cached files. Although, workbox is also keeping the old files (which should be removed whenever sw update is available), but it has now stopped referring to old files (the cause of 'Unexpected token <' error). I simply followed the advanced recipe as prescribed on this page, with the prompt removed. Apparently removing the prompt had an effect on workbox properly loading the updates. |
Sharing an update - redeployments are not breaking any service worker logic now. Followed the advanced recipe as suggested in Workbox guides (minus the prompts) + manually handled cache refresh inside workbox's 'waiting' handler. |
Hey @sharanan-sarvsutra , can you share a gist/code of how you are doing the manual cache refresh and service worker updating logic. Thanks. |
workbox sw config:- to refresh cache:- |
@jeffposnick @sharanan-sarvsutra
But I wonder, Is there another way than reloading again after the SW updated in order to prevent the error occurring when precached resources mismatch due to hashes in their url.
Thanks for some clarification. |
@sourybunny were you able to find a solution here? We're encountering identical behaviour here. |
This issue still exists, So the solution is to add
|
Library Affected:
"@vue/cli-plugin-pwa": "^3.6.0",
Browser & Platform:
Google Chrome for Android
Issue or Feature Request Description:
I bundle my website/PWA, where I use a couple of Web Components, using the workbox-webpack-plugin.
Everything works smooth and well till I redeploy the project (hosted on Netlify).
On my phone/desktop, if I clean my cache and access the website/pwa, all good, worker works correctly.
Later on, once I release a new version, where I did several changes, and deploy it to the hosting and if I try to access the website/pwa , then I'll face the following error:
Uncaught SyntaxError: Unexpected token <
On checking network requests, I see that a request is made to an older app.[hash].js file which belonged to previous deploy. It is unable to find this file as it is getting deleted when new sw is activated.
const VuetifyLoaderPlugin = require('vuetify-loader/lib/plugin') module.exports = { configureWebpack: { plugins: [ new VuetifyLoaderPlugin() ] }, devServer: { disableHostCheck: true, }, lintOnSave: false, pwa: { workboxPluginMode: 'InjectManifest', workboxOptions: { swSrc: 'src/service-worker.js' } } }
A similar issue is raised #1528 , #1783
Please help.
The text was updated successfully, but these errors were encountered: