Switch from sw-precache to workbox

[FluorescentHallucinogen]

What about use workbox instead of sw-precache in polymer-build to generate service worker code?

[FluorescentHallucinogen]

@gauntface @jeffposnick Could you please help?

[jeffposnick]

We've held off on some of these migrations for the time being, with the idea being that the upcoming Workbox v3 release (roughly: end of October) will be a good time to migrate. That release should generate a comparable amount of runtime code to what sw-precache currently generates, while Workbox v2 generates a larger service worker runtime.

[JosefJezek]

@jeffposnick Alpha is out... https://github.com/GoogleChrome/workbox/releases

[ghost]

I notice VUE CLI got workbox.. What about Polymer :) :)

[JosefJezek]

@rictic Beta is out... https://github.com/GoogleChrome/workbox/releases

[merlinnot]

It is, but I'd not recommend using it just yet. I've implemented it in my app already and it's buggy af.

[FluorescentHallucinogen]

@merlinnot What kind of bugs do you mean? https://github.com/GoogleChrome/workbox/issues/1283? Did you report them? )

[merlinnot]

The one you've linked was (is) rather a feature request. I'm actually watching this repository and they're hammering more and more bugs on a daily basis.

The most annoying one is local development. This is an example of a service worker which would more or less work for most people:

/* eslint-env serviceworker */

'use strict';

importScripts(
  'https://storage.googleapis.com/workbox-cdn/releases/3.0.0-beta.0/workbox-sw.js',
);

workbox.googleAnalytics.initialize();

workbox.routing.registerNavigationRoute('index.html');

workbox.routing.registerRoute(
  new RegExp('https://fonts.(?:googleapis|gstatic).com/(.*)'),
  workbox.strategies.cacheFirst({
    cacheName: 'googleapis',
    plugins: [
      new workbox.expiration.Plugin({
        maxEntries: 30,
      }),
    ],
  }),
);

workbox.routing.registerRoute(
  /images\/.*\.(?:png|jpg|jpeg|svg|gif)/,
  workbox.strategies.cacheFirst({ cacheName: 'images-cache' }),
);

// Expanded during the build process.
workbox.precaching.precacheAndRoute([]);

Given the current Polymer "no compilation step" approach you'd end up having this in your development environment, which would actually require you to enable "bypass for network" mode for the service worker if you're using a standard dev tools like browsersync or polymer serve.

I think it might have something to do with the response headers which Workbox actually checks, there was a PR for this two or three days ago, but I didn't really have time to dive into this.

[jeffposnick]

The release of Workbox v3.0.0 is imminent, and @prateekbh mentioned that he might have some bandwidth to look into switching over (which involves a decent amount of TypeScript, I gather).

[prateekbh]

I'll try to open a PR soon with workbox integration, and we can take the discussion from there.

[FluorescentHallucinogen]

Looks like the stable v3.0.0 of Workbox has been released: https://github.com/GoogleChrome/workbox/releases/tag/v3.0.0. :tada:

[prateekbh]

yep the PR is WIP. Hopefully will get it out this week

[davidmaxwaterman]

FWIW (which might not be much), my experiences with workbox have been mostly negative compared to what was used previously (sw-precache). I am comparing a PWA I developed using Polymer 2.0's PSK compared to a subsequent version developed by someone else using lit-html (and other libs) and workbox. The main problems I've seen are actually more to do with dev tools, and problems with clearing the cache/etc during development; not just when served from localhost, but also from an https web site. I admit that I don't fully understand what is happening, but after trying various things over a few months to try to get the app back to it's initial state, I have found that using chrome://serviceworker-internals to stop and unregister the service worker, and then using the dev tools to clear out the cache and other storage, to be reasonably successful. However, it seems most successful to simply do development in an incognito window, where I am reasonably sure everything starts from scratch. Since I don't fully understand the use of workbox, I can't really figure out what the problem is, so don't feel able/qualified to file a bug on it even. Perhaps Workbox will be deployed in a way that is more predictable than I've seen, but I would still advise caution and be sure to fully test out how easy an app developed using this is to 'control' in the dev tools, compared to the previous/existing method.

[JosefJezek]

Workbox v4.2.0 is out https://github.com/GoogleChrome/workbox/releases

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed after being marked stale. If you're still facing this problem with the above solution, please comment and we'll reopen!