chore(cloudflare): optimize Cache usage; strict TS source

[lukeed]

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Rely on the Cache API sooner within adapter-cloudflare. Makes use of worktop for all Cache operations, which safely writes a Response into the Cache only when permitted.

Also converted the _worker.ts file to TypeScript for strict type checking, which is doable since we build with esbuild anyway.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: c0724b2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/adapter-cloudflare	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[lukeed]

Raised internally – i think the Pages application is misconfigured. It has:

[build.command]
pnpm build --filter="@sveltejs/kit" --filter="@sveltejs/adapter-cloudflare" --filter="@sveltejs/adapter-auto" --filter="create-svelte" --filter="default-template

[output]
packages/create-svelte/templates/default/.svelte-kit/cloudflare

but that output directory doesnt exist when run locally. True for the default branch too

[lukeed]

CI is passing. Pages app seems unrelated

[Rich-Harris]

The .svelte-kit/cloudflare output directory does exist locally if you set CF_PAGES=1 (which is how adapter-auto detects that it needs to delegate to adapter-cloudflare). The build failure is being caused by this...

13:46:21.752 | packages/create-svelte/templates/default build: > Using @sveltejs/adapter-cloudflare
-- | --
13:46:21.753 | packages/create-svelte/templates/default build:   Detected environment: Cloudflare Pages. Using @sveltejs/adapter-cloudflare
13:46:21.780 | packages/create-svelte/templates/default build: ✘ [ERROR] Could not resolve "worktop/cfw.cache"
13:46:21.780 | packages/create-svelte/templates/default build:     .svelte-kit/cloudflare-tmp/_worker.ts:3:23:
13:46:21.781 | packages/create-svelte/templates/default build:       3 │ import * as Cache from 'worktop/cfw.cache';
13:46:21.781 | packages/create-svelte/templates/default build:         ╵                        ~~~~~~~~~~~~~~~~~~~
13:46:21.781 | packages/create-svelte/templates/default build:   You can mark the path "worktop/cfw.cache" as external to exclude it from the bundle, which will remove this error.

...which makes me think it is related to this PR

[lukeed]

Ok so then it must be a resolution thing? Because running build w/o the CF_PAGES=1 env is successful.

But yea, can now reproduce if I repeat with CF_PAGES present

[lukeed]

Ah. Fails because the default template is built from within the create-svelte package (packages/create-svelte/templates/default/.svelte-kit/cloudflare-tmp) and the worktop package isn't resolvable from that location since root & create-svelte don't have it installed. This would be true for any runtime dependency, which none of the other adapters currently have.

[Rich-Harris]

Of course, that makes sense. In other adapters, we solve this problem by bundling earlier. We could do that here: #4473

[Rich-Harris]

This LGTM but I'll confess I don't really understand why we need this to be a .ts file. I get that it doesn't make a huge difference seeing as we're bundling with esbuild, but I think there's probably some value in using .js consistently across the entire repo, rather than introducing an exception. Opened #4474

[lukeed]

I don't really care about *.ts or not – esbuild is already there so it's free either way. I just want the strict types loaded to further prevent type & usage errors we saw in the originating Module Worker transform PR