Default Service Worker (in demo app or/and docs)

[Mlocik97]

Describe the problem

Let think about default configs and options and some features for svelte-create. I think, now configuring svelte takes a little more steps than is necesary. (mainly point 3 and 4 below)

Describe the proposed solution

Today we have:

• 1. Demo app as default template, I think Skeleton one would be better (as is more often used)
• 2. app.html as default template html file, why it's not index.html (index.html is "standard")
• 3. what about adding another option to CLI svelte-create "create service-worker"? It could probably use modified sapper service-worker file - https://gist.github.com/Mlocik97/cf0f4c39e46d45404fda8808a25244c8
• 4. it would be probably nice and faster to add option to CLI create-svelte to choose from some adapters: like "use node adapter", "use static adapter", "I will choose adapter later" options. (when using node adapter, it can also add "start": "node ./build" to package.json scripts. Include a default adapter for the demo project #2459

Alternatives considered

Let it be as it is now.

Importance

nice to have

Additional Information

No response

[dummdidumm]

1. I would keep it for Demo app as the default. The onboarding experience for new users should be the priority here, and them having a nice demo project scaffolded by default is better
2. No opinion on this. I remember there were some reasons for naming it like this.
3. Maybe, but this sounds like a ticket on its own.
4. We thought about this, too, but didn't add it yet, mainly because we were unsure if this is too much decision load upfront. But the default could be "I don't know yet / a different adapter". The problem with a list of adapters is that we could only reasonably add the officially maintained ones, but there are a lot of community adpaters (hopefully) which may feel left out then.

[Rich-Harris]

1. Agree with @dummdidumm
2. index.html implies it only applies to /
3. We should probably add a service worker to the demo app (which needs to be overhauled for a variety of reasons), and the documentation should probably include a sample service worker or two
4. solved with adapter-auto

[Mlocik97]

ok, I agree with 1 and 2...

about 4, I wrote it in time when adapter-auto didn't exist,... it's good it's added. It's why I checked it.

about 3. agree, docs with link to demo service-workers or including one in demo app would be really good.

[jochemvogel]

Just adding my two cents. No idea if it's valuable, but I'm just going through all the 1.0 issues and try to help where I can. Maybe these links can help with adding the sample service workers?

Wrote an article about a service worker implementation a year ago: https://jochemvogel.medium.com/how-to-cache-dynamic-pages-on-demand-with-a-service-worker-in-sveltekit-4b4a7652583d

Also implemented one lately in another project: https://github.com/jochemvogel/ictmethods.nl/blob/development/src/service-worker.ts

Please let me know if I can help with anything.

[narender2031]

Documentation for configure the SSR call for server side only is also missing. We can add that also.
Please add your thoughts. @Rich-Harris @Mlocik97

[madeleineostoja]

Stumbled across this while looking for guidance on service workers in kit, agree that the current documentation is pretty lacking and assumes a high bar of knowledge for configuring service workers given what the $service-worker module provides, would be very low-hanging fruit to help with onboarding to sveltekit before 1.0 imo

[SarcevicAntonio]

Was using Workbox Modules like workbox-precaching and workbox-routing considered?

This could make it easier for the reader, as we aren't coding the caching ourselves. Example implementation for precaching the app shell:

import { build, files, prerendered, version } from '$service-worker'
import { cleanupOutdatedCaches, precacheAndRoute } from 'workbox-precaching'

const precache_list = ['/', ...build, ...files, ...prerendered].map((s) => ({
	url: s,
	revision: version,
}))

precacheAndRoute(precache_list)

It almost works out of the box, we'd just have to define process.env.NODE_ENV via Vite config.

	define: {
		'process.env.NODE_ENV': '"production"',
	}