Unexpected behaviour when manually constructing PrecacheController

Library Affected: workbox-precaching

Browser & Platform: Google Chrome latest

Issue or Feature Request Description: Using Workbox v5.1.4.

I have a use case where I want to fully utilise the precaching of my app shell, besides in the scenario where our server deems under certain circumstances that the user should be redirected. This redirection will occur on the base route / . This redirection will then be handled by the precacheController using the registered index.html asset given to precacheAndRoute, serving the user the cache index.html app shell rather than the browser redirecting to the page being served by a different server (same origin).

I have tried constructing my own precacheController and invoking install manually on it, inside the install listener. Passing install a plugins array containing a cacheWillUpdate plugin. Ideally preventing installation of the service worker if the redirect on / is present. Causing the user to be redirected correctly.

// issue lies here This approach appears not to be very consistent, depending on the order i construct things, i either never get a successful installation of the service worker on first load (on 200 where the index.html should be cached). Or an error is thrown when trying to grab index.html “c.handle is not a function” (minified workbox). I’ve added a default handler for it to fallback on, however it seems to be trying to call handle on the PrecacheController instance rather than its handler…

// Attempts to work around Furthermore, I have also tried registering a NetworkFirst strategy for just the index.html before the precacheAndRoute is called with the assets. This works great, however, i then lose the Navigation routing from createHandlerBoundToURL on longer urls and ones with queries, which is very important for our use-cases!

It seems like in Workbox v6 the PrecacheController has changed slightly to accept plugins as a parameter in its constructor. However i would not like to update as i’m using create-react-app for my webpack config.

import { clientsClaim } from 'workbox-core';
import { precacheAndRoute, PrecacheController } from 'workbox-precaching';
import { registerRoute, setDefaultHandler } from 'workbox-routing';

clientsClaim();

// precache all assets from the /build folder.
precacheAndRoute(self.__WB_MANIFEST);

const preCacheController = new PrecacheController();

const fileExtensionRegexp = new RegExp('/[^/?]+\\.[^/]+$');
// Handle navigation routes.
registerRoute(
  ({ request, url }) => {
    if (request.mode !== 'navigate') {
      return false;
    }

    if (url.pathname.startsWith('/_')) {
      return false;
    }

    if (url.pathname.match(fileExtensionRegexp)) {
      return false;
    }

    return true;
  },
  preCacheController.createHandlerBoundToURL(process.env.PUBLIC_URL + '/index.html')
);


setDefaultHandler(({ url, event, params }) => {
  return fetch(event.request);
});

self.addEventListener('install', (event) => {
  const plugins = [
    {
      cacheWillUpdate: ({ event, request, response }) => {
        if (response && response.status && response.status >= 300) {
          return false;
        }
        return true;
      }
    }
  ];
  
  event.waitUntil(
    preCacheController.install({ event, plugins })
  );
});
// more unrelated service worker code below.

[jeffposnick]

Yeah, I’d switch to c-r-a v4 at this point if you’re having any issues with c-r-a v3’s config. That should give you the flexibility to make any changes to the underlying service worker file to, e.g., account for something in your publicPath prefix (which sounds like what you might have been running into).

[JordanPawlett]

Thank you for clearing up the whole listener thing!

I’ve been using service-workers passively for a while. But it’s only been in the past 2 days i’ve really deep dived into all their capabilities, particularly surrounding workbox.