I know it’s been almost three years... but I’m going to resurrect this because I’ve got a project where this would be a very valuable feature and it might be worth my while to draw the rest of the proverbial owl.

Essentially, I’m working on a SvelteKit app which has a lot of dynamic routes, most of which have data which can be stored/cached in IndexedDB (or an alternative storage solution). Currently, I can access IndexedDB in +page.ts, but that’s only available if the user has already visited the page. As a fallback, the service worker can serve a cached page, but that’s only possible if the user has previously visited the page. There would be some enormous user experience wins if the service worker could sensibly respond to any request.

The sort of API for this that would address the use cases I have would be:

• The $service-worker module should export a respond function, which takes a FetchEvent and returns a Promise<Response>. The respond function would mostly work like the Server#respond method made available to adapters.
• Any module available on the client would be made available in a service worker, such as $app/environment. This could be a separate issue, I don’t see what the problem would be with this besides needing sensible defaults.
• $app/environment could provide a serviceWorker export, analogous to browser.
• In a service worker, +layout.ts and +page.ts would run, but +layout.server.ts and +page.server.ts would not be run. Instead, there would be a +layout.worker.ts and +page.worker.ts files instead. +{layout,page}.worker.ts would be given a server() function, similar to how parent() works, and would get the properties available on FetchEvent instead of platform.
• In a service worker, a +worker.ts file would substitute for +server.ts. Again, +worker.ts would be able to call sever() to run the +server.ts endpoint.

The SvelteKit codebase seems to have changed a bit since I last attempted a PR which added this functionality so I wouldn’t mind some guidance as to what a ‘mergeable' implementation would look like. In particular, I think there’s a trade-off to be made between flexibility and maintainability when it comes to how much code can realistically be shared between the server and service worker implementations — would an internal sui generis adapter for service workers be an option?