Workbox: [next] workbox-window feedback when used in a webpack project

[jadjoubran]

Library Affected:
workbox-window, workbox-webpack-plugin

Browser & Platform:
N/A

Issue or Feature Request Description:
I'm in the process of implementing workbox-window beta.2 in a webpack project.
I previously implemented workbox-window beta.1 in a 1 page project without webpack and it was very smooth (and we discussed feedback on twitter).

Now I'm trying to do the same but in a webpack project, and I faced a couple of issues. Now that I'm now using beta.2.

1. It seems that I can't import external URLs when in a webpack project. Thus this import is breaking:

import {Workbox} from 'https://storage.googleapis.com/workbox-cdn/releases/4.0.0-beta.2/workbox-window.dev.mjs'

It also doesn't work as a dynamic import for the same reason. So the only reason to make it work would be to use dynamic import with a webpackIgnore: true:

import(/* webpackIgnore: true */'https://storage.googleapis.com/workbox-cdn/releases/4.0.0-beta.2/workbox-window.dev.mjs').then(module => {
   //module.Workbox
})

However this means that it would fail on Firefox & Edge as they don't have support for dynamic imports at the moment.

1. I thought about using copyLibraries to be able to import a local file. This would forced me to download workbox-cli@beta in addition to the existing workbox-webpack-plugin@beta. It also complicates the build step a little build because the copyLibraries command needs to be called every time)
   This isn't possible with beta.2, but will be possible with beta.3 since @jeffposnick merged the fix 2 days ago.

2. I'm not really sure if I'm doing something wrong but this is failing with an error saying that the service worker file could not be found:

import { Workbox } from "./../workbox-window.dev.mjs";

const workbox = new Workbox("/sw.js");

workbox.register().then(response => {
});

I don't want this to end up as a question, so if you think I'm doing something wrong I'll figure it out myself.

1. This one is less important but relates to DX:
   Having to manually switch from workbox-window.dev.mjs to workbox-window.prod.mjs is sub-optimal. Would it be possible to automatically load helpers only on localhost just like it's done in the service worker?

I'm curious to see if other people are facing the same issues before workbox 4 is in release candidate. I might be able to send PR(s) for some of these, so looking for feedback from @philipwalton and Jeff first.

[philipwalton]

Did you try doing this? It should work with either Webpack or Rollup:

import {Workbox} from 'workbox-window';

You could also specifically import just the Workbox.mjs file like so, which may be better for Webpack (since I'm not sure how sophisticated its tree shaking is):

import {Workbox} from 'workbox-window/Workbox.mjs';

BTW, I have a draft of a guide on using Workbox with bundlers (which I'm waiting until v4 is released to publish since certain conventions won't be true) until then, but I thought you may find it helpful, and I'd love any feedback you have on it.

[jadjoubran]

Thanks the import from package name fixes it 👍
I originally tried with npm install workbox-window which installed the stable release of 4.0.0-beta.1
and my code worked (except for the messageSW part but that might be something wrong on my end).

1. However upgrading to 4.0.0-beta.2 (with an npm install workbox-window@beta) breaks with a 404 just like what I reported yesterday.
   So it seems like the new issue was introduced in beta.2
   Looking at the logs, it seems that workbox-window is trying to fetch /undefined
   

2. Another unexpected behavior I noticed is that the waiting event files only the first time it becomes waiting. If you reload the page afterwards, it doesn't fire again.

I'll check the doc and add comments (if any)

[philipwalton]

Ahh, I think I see the problem. Did you notice the API change to the Workbox constructor posted in the release notes?

Where you have this (which worked in beta.1)

const workbox = new Workbox("/sw.js");

It should now be this for beta.2:

const workbox = new Workbox({scriptURL: "/sw.js"});

But just to warn you, we decided to revert that change (since we decided not to ship the scriptVersion option yet), so in the next release your code will need to go back to how it is today (sorry for all the changes!).

We're planning to release an update next week, so if you just want to wait for that, it might be easier.

[jadjoubran]

ah makes sense, I did see it but didn't notice the object signature, so I thought they were 3 different args
Okay thanks 👍 I'll wait for beta.3 and test again

[jadjoubran]

Tested on rc.0 and
1, 2, 3 and 4 are working properly 👍 thanks 😄

The new "window" code is so much cleaner and eloquent than before.

It seems though that it's not possible to trigger skipWaiting when the "waiting" event triggers with the new approach because of this warning:

workbox-core.dev.js:1595 Event handler of 'install' event must be added on the initial evaluation of worker script.

So is that not possible before workbox-window #1848 is implemented?

One the window, I'm addingEventListener for "waiting" and then I send a messageSW("skipWaiting") and then the service worker triggers workbox.core.skipWaiting()

self.addEventListener("message", event => {
  if (event && event.data === "skipWaiting") {
    return workbox.core.skipWaiting();
  }
})

[philipwalton]

Ahh, I think you're getting this warning because you're using workbox.core.skipWaiting() instead of just calling self.skipWaiting() directly.

If you look at the implementation for workbox.core.skipWaiting(), you can see it adds an event listener, which triggers that warning when done after the initial evaluation of the service worker:

const skipWaiting = () => {
  addEventListener('install', () => self.skipWaiting());
};

[jadjoubran]

Ah yeah good point 👍 I still can't get it to work with self.skipWaiting() but I'll take a look and debug.

So I just one more "unexpected" behavior with workbox-window, which is the following:

1. Web app with SW v1 installed.
2. Create a new version of the SW (SW v2)
3. Open the page, you will see the console.log Waiting (which means "waiting" event is triggered).
4. Reload the page, you won't see the Waiting log anymore. So it only shows up once. Is that an intended behavior? or is it because "reloading" is still being served by the same instance of the service worker.

const workbox = new Workbox("/sw.js");

workbox.register().then(registration => {
  console.log({ registration });
});

workbox.addEventListener("waiting", event => {
  console.log("Waiting");
});

[jeffposnick]

I believe that the changes introduced in https://github.com/GoogleChrome/workbox/releases/tag/v4.0.0-rc.3 addresses these points.

@jadjoubran, can you confirm that you can use workbox-window in a way that meets your requirements now, and that we can close this issue?

[jadjoubran]

Yes I can confirm that with rc.3 the waiting event now fires every time I reload the page (as long as there's an sw in waiting state)
Thanks a lot Philip & Jeff 😃