feature: Service worker (custom Astro integration)

[decrek]

Changes

• Add service worker setup with basic network first strategy on HTML pages
• Made the decision to go for my own custom integration. It can serve as an example integration and I like the fact that we build our own service worker from a service-worker.ts file instead of generating one. I feel this is the most understandable for others and gives you maximum freedom over its implementation.

Associated issue

Resolves #199

How to test

1. Open preview link
2. Open devtools --> Application
3. Verify a service worker is installed
4. Go offline, refresh the page and verify that the HTML page is still served

Checklist

• I have performed a self-review of my own code
• I have made sure that my PR is easy to review (not too big, includes comments)
• I have made updated relevant documentation files (in project README, docs/, etc)
• I have added a decision log entry if the change affects the architecture or changes a significant technology
• I have notified a reviewer

[cloudflare-workers-and-pages]

Deploying head-start with    Cloudflare Pages

Latest commit:	a061c0c
Status:	✅  Deploy successful!
Preview URL:	https://5d76137e.head-start.pages.dev
Branch Preview URL:	https://feat-199-add-service-worker.head-start.pages.dev

View logs

[jbmoelker]

I think I would move this file to config/astro/service-worker-integration.ts or config/astro/integrations/service-worker.ts, since it's basically a configuration snippet that's loaded into the main astro.config.ts. Whereas /scripts/ contains all scripts that are executed from a cli context.

[jbmoelker]

I think within an Astro integration you have access to the configured src and dist directory (srcDir and outDir on the config param) (reference).

So I would change the API of the serviceWorkerIntegration so it can be called as something like:

serviceWorkerIntegration({
  srcFilename: 'assets/service-worker.ts', // relative to `srcDir`,
  outFilename: 'service-worker.ts',        // relative to `outDir`,
})

[jbmoelker]

Maybe this can be simplified by declaring self?:

/// <reference lib="webworker" />
declare const self: ServiceWorkerGlobalScope;

[jurgenbelien]

I looked at this with @decrek and there are two ways to do it:

declare const self: ServiceWorkerGlobalScope;
export default null // or export default {}

or do the self-invoking function to assign it to a new similarly named variable.

Without the export statement, it'll throw errors. Since the service-worker is specifically not meant to be imported, the self-invoking function made more sense.

[jbmoelker]

Yes, I read that in fact. I would opt for declare + export default null (with a comment). Since I think the expected behaviour is that you can write self.add... in the root. So I think we should write the plumbing to make that work.

[jbmoelker]

PerfHead sounds like the perfect location for this :)