templates(cloudflare-workers): use static assets

[edmundhung]

This PR updates the cloudflare-workers template to use the Static Assets feature announced today.

Note: Static assets is currently in open beta

You can learn more about Static Assets in the documentation.

Closes: #

• Docs
• Tests

Testing Strategy:

To test, please run create-remix with the template on my fork

npx create-remix@latest --template edmundhung/remix/templates/cloudflare-workers

Then deploy it with wrangler by running:

npm run deploy

Woohoo! Your Remix app is now running on Cloudflare Workers: https://template.remix-run.workers.dev

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1c039ca

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[tsteckenborn]

@edmundhung while you're on it, shouldn't https://github.com/edmundhung/remix/blob/1b52fe4b118735692b94d5338fca39c1b8bc55ae/templates/cloudflare-workers/app/root.tsx#L8 and https://github.com/edmundhung/remix/blob/workers-assets/templates/cloudflare-workers/app/routes/_index.tsx be from @remix-run/cloudflare?

[ayuhito]

I've been testing this template and it's been working flawlessly. However, has anyone else managed to make the asset binding work? I keep getting TypeError: Cannot read properties of undefined (reading 'fetch') when using the Fetcher interface of the asset binding.

This only occurs when running the dev script with remix:vite dev. wrangler dev seems to work, although that requires the whole build step.

[tsteckenborn]

@ayuhito are you when running pnpm devalso seeing the state error or is that something on my machine? 😕

So it's showing the page, but I'm seeing the error in the terminal.

> remix vite:dev

Re-optimizing dependencies because lockfile has changed
  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help
TypeError [ERR_INVALID_STATE]: Invalid state: Controller is already closed
    at ReadableByteStreamController.close (node:internal/webstreams/readablestream:1157:13)

[laishere]

@edmundhung while you're on it, shouldn't https://github.com/edmundhung/remix/blob/1b52fe4b118735692b94d5338fca39c1b8bc55ae/templates/cloudflare-workers/app/root.tsx#L8 be from @remix-run/cloudflare?

And this too, they are from the old commits:
https://github.com/edmundhung/remix/blob/1b52fe4b118735692b94d5338fca39c1b8bc55ae/templates/cloudflare-workers/app/routes/_index.tsx#L1

[ayuhito]

also seeing the state error or is that something on my machine?

Nope. I've got a different error to that. I was alluding to the fact that cloudflareDevProxyVitePlugin might not perfectly handle the static assets interface in my comment.

[FraBle]

Is there any rough timeline for when this PR might land? (excited about using it)

[petebacondarwin]

This looks good to me. If we can land this we can fix up the create-cloudflare tool to point to it.

[focux]

Does this same setup work for SPA mode?

[acusti]

Static Assets (aka Workers Assets) is currently in beta, but according to the Wrangler configuration docs, Workers Sites has been deprecated in favor of Workers Assets:

site object optional deprecated

• See the Workers Sites section below for more information. Cloudflare Pages and Workers Assets is preferred over this approach.

also, i’ve been using it in production (same as the implementation introduced here) without issue for a few weeks now.

my only comment on this PR is that i’m not sure whether or not it’s worth including the custom getLoadContext pattern for augmenting load context, because it seems like more of an advanced pattern. but it also seems pretty harmless, and maybe it will help template consumers discover the pattern if they find the need for it, so i don’t mind either way.

---

@focux i haven’t tried it, but i can’t imagine why it wouldn’t work for SPA mode. the static assets feature matches any request to any file in the specified directory (./build/client/ in Remix), so it serves any built JS and HTML (and any other static files placed in the ./public/ directory) automatically.

---

@FraBle you can use this right away for new projects by using the fork:

npx create-remix@latest --template edmundhung/remix/templates/cloudflare-workers

or just manually apply the diff of this PR to an existing Remix / Cloudflare Workers project if you have one.

[MichaelDeBoey]

Suggested change

	export function getLoadContext({ context }: GetLoadContextArgs) {
	return context;
	}
	export const getLoadContext = ({ context }: GetLoadContextArgs) => context;

[brookslybrand]

This causes a type error, should it just be cast to any?

[laishere]

I think we can just set it to

cf: request.cf!

Or, we can change load-context.ts to:

type GetLoadContextArgs = {
  request: Request;
  context: {
    cloudflare: Omit<PlatformProxy<Env, IncomingRequestCfProperties>, "dispose" | "caches" | "cf"> & {
      caches: PlatformProxy<Env, IncomingRequestCfProperties>['caches'] | CacheStorage;
      cf: Request['cf'];
    };
  };
}

The first is simpler, but the second is better.

[brookslybrand]

I'd prefer correctness, I'll defer to @edmundhung

[acusti]

when I ran into this issue in my own codebase, I looked into it and wound up going with the non-null assertion operator (cf: request.cf!) based on the Cloudflare docs, which explain that “the request.cf object is not available in the Cloudflare Workers dashboard or Playground preview editor”: https://developers.cloudflare.com/workers/runtime-apis/request/#incomingrequestcfproperties

in every other case, the request.cf object is defined and available, so I figured it seemed safe to assert that in this context.

[edmundhung]

The request.cf object is not always available as @acusti shared so I adopted the 2nd solution @laishere suggested.

[AdiRishi]

Really keen for this to land!

I do have a question, I haven't been able to find a good answer to this yet. How can we set cache-control headers for static asssets server via the new method? Previously the ttl was being configured in code, and in Cloudflare Pages it's configured via the _headers file. What's the strategy here? I can see under the new template all assets use public, max-age=0, must-revalidate as the cache control header.

[edmundhung]

Really keen for this to land!

I do have a question, I haven't been able to find a good answer to this yet. How can we set cache-control headers for static asssets server via the new method? Previously the ttl was being configured in code, and in Cloudflare Pages it's configured via the _headers file. What's the strategy here? I can see under the new template all assets use public, max-age=0, must-revalidate as the cache control header.

They are not supported yet. But you can find some workarounds under the Static Assets section: https://developers.cloudflare.com/workers/static-assets/compatibility-matrix/

[brookslybrand]

Looks great to me, thanks so much @edmundhung!

[tsteckenborn]

Is there already a port of this to RR7? @brookslybrand it seems like the type in @react-router/cloudflare over there for the cloudflare createRequestHandler is createPagesFunctionHandlerParams, which might be misleading as it could also be a worker?