/service-worker.js 404

[mrflix]

I'm trying to debug the service-worker offline but can't get the service-worker script to load with the vite dev server.

How to reproduce:

• fresh install
• (edit scripts/buildSw.js:3 require('fs/promises') to `require('fs').promises since the former breaks with node v12.18.3)
• (run npm run build – don't know if it's necessary at this stage)
• enable VITE_ENABLE_SW and VITE_ENABLE_SWR in .env
• run npm run serve

Result

The service worker under http://localhost:3000/service-worker.js fails to load with a 404.

How are you debugging the service-worker locally?

[johannschopplich]

Honestly it's rather tricky to debug the service worker. Your browser won't initialize it in development environment, since 'serviceWorker' in navigator evaluates to false when serving over HTTP. You need at least a self-signed certificate (and then serve via HTTPS within Vite, which in return is complicated) or enable service workers for HTTP connections in your browser settings.

But even if done so, the service worker relies on the generated scripts. Vite doesn't bundle your application. It serves the waterfall of ES modules, only transpiling Vue templates (and TypeScript, etc.) on the fly. So there's no way to make the service worker work which requires the bundled application.

Also, part of the offline capability of the service worker relies on rendered Kirby pages. In local environment, Vite just proxies requests. The template used for the HTML entry point (frontend/index.html) differs from the one used in production (site/snippets/vue-index.php). For example, when offline the service worker falls back to serve the cached index HTML content, which would refer to /src/main.js in development environment. The complete waterfall would have to be cached, which it isn't.

Solution: If you are using macOS with Laravel Valet, you can:

• build your application: npm run build
• self-sign your local testing domain: valet secure kirby-vue3-starterkit
• then run your Kirby instance

This is the only way to debug to service worker at the moment. You can disable Terser on the minified service worker (edit scripts/buildSw.js) to find potential problems.

I've thoroughly tested the service worker over time and improved every bit, so it should work quite well. Of course, I'm open to suggestions! For which feature do you want to debug the service worker, if I may ask?

Thanks for your issue!

[mrflix]

Thanks for the elaborate explanation. At the time of writing I was looking for an error and suspected its origin in the service worker. Turned out it came from somewhere else. Though I might still need to run the service worker offline because I want to add full offlice capabilities with prefetching of all assets (all image sources, source-sets, videos sources and all the json) and that might need some local debugging.

[johannschopplich]

I see. The service worker I created is quite flexible – you can add more cache buckets:

const CACHE_KEYS = {
  // …
  RUNTIME: 'runtime'
}

And then cache everything in there:

// …
} else if (isImage) {
  stashInCache(CACHE_KEYS.IMAGES, request, copy)
} else {
  stashInCache(CACHE_KEYS.RUNTIME, request, copy)
}

Of course this just serves as an example. You can filter beforehand to sort assets into different cache buckets, rather than add everything into one bucket.

---

Testing the service worker offline works fine, just not from within the development server, but after compilation. Therefore I'm closing this. Would be happy to hear, how you extend this starterkit!