Issue with cacheDidUpdate plugin in workbox-precaching when other callbacks are also used

In my application, I display a splash screen and wait for complete the installation of the service worker and only then display the content, because the service worker must manipulate the csp token for several tabs for all requests in the API.

On a slow connection, the installation of a service worker can take up to a minute. I would like to keep the user busy with the progress of caching elements at this time.

I read #2406 and wrote a custom plugin for cacheDidUpdate:

export const cacheDidUpdate = async ({ cacheName, request, old Response, new Response, event, state }) => {
    const { log } = console;
    log('cacheDidUpdate', cacheName, state);
};

I used it in the service worker

addPlugins([cacheDidUpdate ]);

but I didn’t see anything in the console. What am I doing wrong?

[jeffposnick]

(I’ve updated the code sample to use event.type === 'install' instead of event instanceof InstallEvent, since the latter apparently won’t work in Safari, where InstallEvent is not defined in the ServiceWorkerGlobalScope.)

[budarin]

Getting back to your specific usage, apart from all other aspects of this discussion, I would recommend that you don’t add any entries to the precache manifest that is generated by the build tools unless you’re sure that the revision field uniquely identifies the actual content associated with the URL. …

This approach greatly complicates the life of the developer and disorients beginners - static resources and a /?source=pwa router make up the precache list for the application to work offline. You suggest dividing this list and processing its elements in different ways.

If I were developing a workbox, I would implement such a contract

new InjectManifest({
    swSrc: '...',
    swDest: 'sw.js',
    include: [
       { 
          url: '/?source=pwa',  // static resource is generated by server
          revision: <revision>,
       },
       { 
          url: '/anotherStaticResourceFromServer',
          revision: <revision>,
       },
       { url: '*.(js|json)' }, 
       { url: '*.css' }, 
    ],
    addIntegrity: true
}),

And under the hood I would get the integrity attribute for static resources and for static resources from server (with revision) I would do nothing - simply put them as is into manifest assets array.

Thus, the developer would only have to focus on working with the rest of the resources that are not included in the precache list.

P.S: I want to emphasize once again that in this case /?source=pwa and /anotherStaticResourceFromServer are static resources that must be only generated by the product server with its environment and cannot be generated during the build process

for example, ‘/?source=pwa’ route - is an app-shell for the pwa, which is rendered by the server at the request of the client from components that are build and tested during the build process