serwist/next - additionalPrecacheEntries prevents automatically precaching public dir files

[jon-smith]

I'm using serwist/next with a statically exported Next.js app and it's working well, but I'm confused about some precaching options and I'm unsure if it's an issue or I'm using it incorrectly.

I noticed that the index file doesn't get precached by default (I want to ensure this is in sync with the precached js/css files), so I have set up my init as follows:

const withSerwist = withSerwistInit({
	swSrc: 'src/app/sw.ts',
	swDest: 'public/sw.js',
	additionalPrecacheEntries: [{ url: '/', revision }],
});

However this then prevents some files in my public directory from being precached. I noticed in the code (https://github.com/serwist/serwist/blob/main/packages/next/src/index.ts#L165), globPublicPatterns is not used if additionalPrecacheEntries have been set. Is there a reason for this?

The simple workaround is to add my public files to additionalPrecacheEntries but I feel like I might be just using it wrong.

[DuCanhGH]

@jon-smith ah, back in the 8.x days there was no globPublicPatterns, so additionalPrecacheEntries was made a way to opt out of the behaviour where we precache public files. Well, this can be traced back to next-pwa, actually. Still, I guess we can change this in v10 :)

[jon-smith]

Thanks for the response and for creating this as an issue, will keep my workaround for now.

Is there a reason why index.html doesn't get precached by default?

[DuCanhGH]

@jon-smith it is not possible for @serwist/next to know what pages your application may have due to Next.js not exposing that, as far as I'm aware, and pages only being prerendered after webpack has built your application, at which time @serwist/next has also finished bundling the service worker. So, here we are... I'd appreciate Next.js providing some sort of built-in support for service worker like that of SvelteKit, to be honest. Wouldn't want it to be as limited as SvelteKit's though.

[jon-smith]

That makes sense, thanks again!