Deprecate adapter-cloudflare-workers?

[Rich-Harris]

We currently have two adapters for Cloudflare — adapter-cloudflare, for Cloudflare Pages, and adapter-cloudflare-workers for Cloudflare Workers.

Pages includes GitHub integration, preview deployments, etc so of the two it's the one we'd recommend that people use.

Originally we kept both because Pages was in beta, but it's now GA. Does that mean it's time to retire adapter-cloudflare-workers, or are there things you can do with plain Workers that you can't do with Pages?

[Rich-Harris]

cc @jrf0110

[jrf0110]

I'm personally in favor us this. I think when folks are reaching for adapter-cloudflare-workers - and therefore Workers Sites - they're reaching for a legacy experience. I can't say whether or not Cloudflare will be deprecating Workers Sites, but there certainly isn't any active development there.

IMO, deprecate!

[ghostdevv]

For nearly everything you would want pages, but in some situations you might want to run a site on workers - probably if something else is going on. If there is no real maintenance burden then keeping it would be preferable IMO. But it's not the end of the world

[denizkenan]

I, alongside with @dominikg and @gtm-nayan , have spend almost a year on adapter-cloudflare-workers for a project and it was not possible to switch to adapter-cloudflare due to the lack of durable objects binding management in pages(wrangler cli is needed to set it up). In the very beginning, pages also lacked API/UI for managing some advanced functions settings(KV, D1, R2, worker services).

With that said, I am using adapter-cloudflare with kit v1 recently. It seems that Cloudflare matched functions' features with workers.

only downside I see is: currently you can't configure durable object <> cloudflare page functions programmatically like you can in adapter-cloudflare-workers thanks to the use of wrangler. So users need to do it manually in the CF dashboard

TLDR: it would not hurt that much if it gets deprecated

[hmnd]

I use SvelteKit in a monorepo containing various Cloudflare Workers, with my own CI pipeline. Each worker gets deployed to a different route on a single subdomain (eg. workers.mydomain.com/[route]).

Cloudflare Pages originally had to be auto deployed from a git repo through Cloudflare, preventing use with monorepos. But it looks like Cloudflare launched Direct Uploads in Oct. 2022 which should solve the monorepo issue.

However, Cloudflare Pages still (to my knowledge) only allows deploying a single site per subdomain. Given that, I would still prefer if Workers remained supported for now, unless supporting them is a large maintenance burden.

[xpat]

The very clear instruction, "To deploy to Cloudflare Pages, use adapter-cloudflare", gets muddied by the mention of four adapters: adapter-auto, adapter-static and the two cloudflare adapters.

Unless you have a specific reason to use adapter-cloudflare-workers, it's recommended that you use adapter-cloudflare instead.

As long as there are specific reasons and there is still an adapter-cloudflare-workers, maybe the note could read more sharply: Use adapter-cloudflare unless you have to deploy to more than one site per subdomain; unless you have to use ChronTrigger + Scheduled Events; unless ... etc (a list of - ever diminishing? - specific reasons).

And be done with it once there are no more specific reasons -- as Cloudflare does away with Workers? It's confusing.