Query Parameters on the registration URL

[develohpanda]

Hi! Thank you for this wonderful plugin.

I'm working on something that would greatly benefit from being able to pass query parameters to the service worker registration URL. Something like, /sw.js?version=1.0.3. This way, within an incoming service worker I am able to do new URL(self.location).searchParams.get('version'), and pass information to an incoming service worker during updates. (See SO answer)

Example

One example of a use case would be that by sending a query parameter, I am able to convey to an incoming service worker information about the currently running application/service worker. Then, I can check whether the incoming service worker should force-install (via self.skipWaiting() and claim and refresh all clients in the activate event). I will be able to compare the version of the incoming service worker (let's say 2.0.0) with the current application (1.0.3 from the query parameter).

This is useful because it allows the incoming service worker to determine independently it's installation behavior, and we don't need to rely on currently running code (from the assets served by the existing service worker) to do the force update. This is fairly critical to my use case and I'm exploring what options are available.

// sw.js

const version = `2.0.1`;

const url = new URL(self.location);
const currentVersion = url.searchParams.get('version');
	
const shouldAutoActivate = // check whether currentVersion -> version is a minor or major upgrade

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

self.addEventListener('activate', () => {
	if (shouldAutoActivate) {
		return self.clients.matchAll()
		    .then(function(clients) {
				clients.forEach(client => client.navigate(client.url))
		    });
	}
});

Alternative

Is there a way to send query parameters currently, that I am missing? I am using React, and there is not a way to use the useRegisterSW() utility hook to send query parameters, nor a way to set additional query parameters in the VitePWAOptions.

[develohpanda]

Hi @userquin! I've experimented with this locally and it appears to work as intended.

I'd like to make a contribution for vite-plugin-pwa for query parameter support, and I'm wondering whether you (or another maintainer) have input towards what the API might/should look like?

I envision an additional optional property in RegisterSWOptions, used like useRegisterSW({ searchParams: '?foo=bar' }), but with that we'll need to do some funky-logic to combine these params with the dev-sw param.

Please let me know your thoughts!

[develohpanda]

Hi @userquin (or @antfu), sorry to tag you numerous times! I would really appreciate your input before I embark on writing code to raise a PR. 😄

[userquin]

I guess we should add it to custom injectManifest configuration option, this way we can inject the query params in the client and use it also on src/plugins/dev.ts plugin, check src/client/build/register.ts module and dev.ts plugin.

Client injections can be found in src/modules.ts module.

vite-plugin-pwa/src/types.ts

Line 6 in 4d3b1d0

export type CustomInjectManifestOptions = InjectManifestOptions & {

[develohpanda]

If we add query params as a property to CustomInjectManifestOptions, then the query param used in the workbox registration would need to be defined at build time, is that right? I think that works for my use case, but is there value in allowing the query params to be set at runtime via RegisterSWOptions since the params are actually used at runtime?

[userquin]

There should be only one source, if we add the option to the client side, dev will not work.

If we add query params as a property to CustomInjectManifestOptions, then the query param used in the workbox registration would need to be defined at build time, is that right?

No, will work also in dev (when enabled), modules.ts or html.ts modules should update __SW__ properly (I need to check dev.ts plugin, IIRC will need some update to include query params).

Anyway, I have no idea if the browser/workbox will interpret the url with params as a new sw, we need to ensure the sw is the same.

EDIT: in any case, you can register the sw yourself without using workbox-window or adding the logic in src/client/build/register.ts module (injectRegister: null and not using any virtual, IIRC there is an entry in the docs).

[Iran-110]

@develohpanda
For some advanced cache management like you said, this feature is unavoidable. I wrote it in PR #769.