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:	4f9c35a
Status:	✅  Deploy successful!
Preview URL:	https://92cd60c5.head-start.pages.dev
Branch Preview URL:	https://feat-199-add-service-worker.head-start.pages.dev

View logs

[jbmoelker]

Looks good and works well! I pushed some basic documentation and added comments with a few more suggestions.

[jbmoelker]

The esbuild.build config between dev and prod are (and should be) mostly the same (only minify and sourcemap are different). Should we move the shared config up to the root?

const buildConfig = {
    entryPoints: [srcFilename],
    outdir: outFilename,
    target: ['es2020'],
    bundle: true,
    write: false,
    allowOverwrite: true,
}

and use that in both places to keep everything in sync?, like:

const output = await esbuild.build({
   ...buildConfig,
   minify: false,
   sourcemaps: false,
});

[jbmoelker]

Should we consider a package like http-status-codes to write StatusCodes.OK instead of 200? Or simply use some consts at the top, like statusOpaque = 0; and statusOk = 200? Or does this only complicate things?

(ironically that package doesn't have the opaque response status; I also had to look that up. So maybe a comment or link on that would be helpful instead)

[jbmoelker]

We discussed caching assets as well. Do we want to add that to this PR? Something like:

registerRoute(
  ({ request }) => request.url.pathname.startsWith('/_astro/'),
  new CacheFirst({
    cacheName: 'assets',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
      new ExpirationPlugin({
        maxEntries: 50,
        maxAgeSeconds: 30 * 24 * 60 * 60, // 30 days
      }),
    ],
  })
);

What would be good expiration settings?

Or should we match immutable responses instead? Like:

registerRoute(
  async ({ request, response }) => {
    if (!response) return false;
    const cacheControl = response.headers.get('cache-control');
    return cacheControl?.split(' ').includes('immutable') ?? false;
  },
  /* ... same */
);

[jbmoelker]

Should we add config that makes cache cleanup easier in the future? Like:

import { setCacheNameDetails } from 'workbox-core';
import pkg from '@root/package.json';

setCacheNameDetails({
  prefix: pkg.name,
  suffix: 'v1',
});