Closed Snickdx closed 4 years ago
Generating the Service Worker is already taken care of by the Polymer CLI (which is true, uses the old sw-precache), but we could look into having a standalone example of workbox. The problem (in my mind) is that if you’re not going to use polymer build
to bundle your app and generate your service worker, then you’re gonna have to do your own rollup and stuff too, so I feel you’re on an offramp you don’t need a lot of hand holding for. What do you think?
I know there's a lot of overlap between the two, but for what it's worth I'd also prefer to use workbox. It has good tooling support, though, and I suppose there's essentially nothing stopping one from re-generating and overwriting the service worker using the workbox cli after polymer build.
The motivation behind workbox over sw-precache is that it supports the dynamic data caching, background sync, and templated service worker much better than sw-precache. Although, that might just be because I'm much more interested in the offline/poor network support parts of PWA.
This might be something easily solved by a bit of documentation? Showing how to set up workbox on top of the starter kit? Thoughts? 🤔
Oh, maybe it'd be better for polymer to consider workbox-build for their service-worker then? In any case I guess workbox could just be ran in the kit like Mike said.
The migration from sw-precache
to workbox
issue exists since a lot of time. A guy actually opened a PR for it, but since then polymer-build
has been moved to the Polymer tools monorepo. Reading the comments on his PR, it seems like he is already working to reopen it in the new repo. However, the problem is that it would be a breaking change, since workbox
and sw-precache
require different configurations. Guess we'll have to wait and see what happens
Moving the PR today
Unsure if this is related to the topic - anyway: I am facing that the page is not updating @ mobile because of service-worker. Should we use a kind of hash
in our build process? Meaning - if example view-1 is updated and deployed - a user with a network connection should see the update. With a new build - hash or something we could force to update all the "assets". Not?
The generated SW (whether by polymer-cli, sw-precache, or workbox) will include a hash of precached assets (e.g. https://pwa-starter-kit.appspot.com/esm-bundled/service-worker.js). If this hash is changed in a new version of the SW, that assets will be reloaded and available on the next page load.
This should be fixed by https://github.com/Polymer/tools/pull/388
If you want to use Workbox in the meantime, you can remove addServiceWorker
from polymer.json, then, after polymer build
, use Workbox to generate an SW from the build output.
Could we have this for before 1.0?
We don't expected major updates to polymer-cli/build before 1.0, so no. Again, it's possible to opt-out of polymer-cli SW generation by removing addServiceWorker
from polymer.json, then, after polymer build, use Workbox to generate an SW from the build output. Example workbox config can be found in the webpack branch:
We don't expected major updates to polymer-cli/build before 1.0, so no. Again, it's possible to opt-out of polymer-cli SW generation by removing
addServiceWorker
from polymer.json, then, after polymer build, use Workbox to generate an SW from the build output. Example workbox config can be found in the webpack branch:
@keanulee & @frankiefu : Do you know if a codelab exist in order to set up the pwa-starter-kit to use webpack thus ease the set-up to migrate from sw-precache to workbox ?
Thanks
Hey @Yuen92!
There are a few branches set up with webpack configured, depending on which options you would like (check this one out as a start). I've used them successfully as a seed for a project, it does what it says on the box. The only caveat is that you lose some of the differential builds with webpack. As it's configured, it produces an es5 build only and not ESM/ES6.
Hello there, I saw this one is still open. We have a branch with Workbox V3 and Typescript (“template-typescript-webpack”). When updating to V4 you might see this deprecation warning:
WARNING in Specifying 'staleWhileRevalidate'' in a 'runtimeCaching[].handler' option
is deprecated. Please update your config to use 'StaleWhileRevalidate' instead.
In v4 Workbox strategies are now classes instead of functions.
You have to replace the string in the handler to solve this deprecation issue.
Replace handler: 'staleWhileRevalidate'
with handler: 'StaleWhileRevalidate'
I am working on that branch and it seems to be working well with V4 so far.
This project is no longer under development and will be transitioning to a read-only repo. Thank you for your contributions.
Maybe consider adding workbox to the kit? Really nice developer experience and documentation.