I can look into this feature in the coming days to see how feasible it would be to introduce it as a PR, however, if the issue requires more significant changes to the adapter I might want to wait and consult some others to learn more about the impact this feature request might have.

I have done some more research and found a few areas the adapter can be improved. Namely, the documentation needs a significant upgrade. The documentation is confusing for new users and does not explain what the toml file should look like. Secondly, the adapter does not currently use kv-asset-handler to its full potential and does not set any browser cache headers on the static files served. At the very least, the adapter needs to include some way for users to be able to specify their cache preferences for static files. In light of all of these changes, I have determined that its best to refactor the module to output code in the esm format, rather than the node format previously used. This will have numerous advantages, but the primary motivation for implementation was that it is ESM modules are a prerequisite to using Durable Objects.

Unfortunately, I am struggling with getting ESBuild to bundle the dependencies of a sample project in when using format: 'esm'. format: node works perfectly, but when changing the format, the dependency resolution strategy is somehow altered.

Any help or clarification would be much appreciated!

As a short update;

I managed to get the module syntax fully compiled. I am just waiting for cloudflare to merge my PR of kv-asset-handler which introduces support for the module syntax there. The adapter also has some new configuration options so my PR will include some changes to the documentation.

Most notably however, my PR will introduce a breaking change. This will likely need to be discussed further with a larger group of the community. The reason I would like to introduce the breaking change is that eventually cloudflare plans to deprecate the old syntax, and force usage of their new modular syntax. For this reason, I think it makes sense for the modular syntax to be the default for all workers created using this adapter.

Luckily, the breaking change in question can easily be mitigated with a clear and concise message informing the users of how to adapt their project to compile, and it only requires a minor two line change to their wrangler.toml. In all, I think this breaking change will serve to better the adapters position in providing users with another deployment option for their sveltekit sites.

I have the code ready for a PR, I just need to wait until this PR is merged first.
cloudflare/kv-asset-handler#200
So I will be following this PR closely and will submit mine here on sveltekit once it has been merged and pushed to NPM

So, few things going on here:

(@DrewRidley and I also spoke in Discord a little bit, so this won't be anything new)

Durable Object (DO) development is heavily tied to the ESM format for Workers. So this means that while DOs are in beta (they still are), the ESM format is in beta too, by extension.

The adapter should 100% be outputting the ESM variant code only – so that the developer has the freedom to opt into DOs if/when they see fit. However, SvelteKit shouldn't be doing this until DO/ESM development is out of beta. Personally, I have no idea if there are other breaking changes on the docket for either of these, but DO is still under "beta" label intentionally, reserving that right for "last-second" changes.

The kv-asset-handler package will surely be updated once ESM/DOs are out of beta – maybe before (I don't know). I'm sure DO going into GA will be the signal that a lot of projects were waiting for before making compatibility changes, my personal projects included.

@DrewRidley Changing the platform option for esbuild changes its resolution paths; see here. I use none & control the resolution via hardcoded mainFields and conditions values.

@lukeed @DrewRidley Durable Objects are now GA. Do you have the PR?

Sorry for the delayed response! It looks like the best way to support durable objects is to have a folder of durables that is detected and injected by the adapter. I can have a PR done within the next few days. As for websockets it's probably best that we transparently pass them through in the adapter, and let the user implement them using hooks.

Any update on this @DrewRidley?

adapter-cloudflare-workers is now ESM-based, and provides access to env and context (via event.platform). Aside from inconsistency between dev and build, which is covered by #3535 and #4292, is there anything more to do here?

I'm interest in this part. A home for the DO classes and getting them compiled correctly. Seemingly need to be concatenated?

It looks like the best way to support durable objects is to have a folder of durables that is detected and injected by the adapter.

EDIT: The below DOES NOT work, as is.

Problem

Durable Object classes have to be defined as named exports on the main module (i.e. the Worker module). Users don’t have a way to edit the main module provided by the adapter (short of creating a custom adapter).

With Wrangler 2, this is no longer an issue.

Solution

Unlike Wrangler 1, Wrangler 2 can resolve es modules. Simply re-export default from the output main module like so…

// @file ./custom-worker-entry.js

export { default } from "./.cloudflare/worker.js";

export class MyDurableObject {
  // …
}

…and update wrangler.toml.

- main = "./.cloudflare/worker.js"
+ main = "./custom-worker-entry.js"
  site.bucket = "./.cloudflare/public"

+ [durable_objects]
+   bindings = [{
+     name = "MY_DURABLE_OBJECT",
+     class_name = "MyDurableObject",
+   }]

If you change main to ./custom-worker-entry.js, then ./.cloudflare/worker.js will no longer be created, so I don't think this will work?

export { default } from "./.cloudflare/worker.js";

It seems like we would probably need a way to tell the adapter where our DOs are defined, so that it can then inject something like

export * from '../src/my-durable-objects.js';`

(which I assume works? will confess only passing familiarity with DOs)