chore: check WORKERS_CI env variable to determine if we're building for Cloudflare Workers

[teemingc]

Inspired by unjs/std-env#156

This PR detects the WORKERS_CI environment variable so that adapter-auto and adapter-cloudflare can work with Cloudflare's Workers Git integration to build the app without requiring a wrangler configuration from the user.

I've changed the scope of the PR to focus on only the Cloudflare adapter because we'll may end up deprecating adapter-auto. Also, it doesn't work well with adapter-auto since it requires a wrangler config file.

---

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.

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 pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

🦋 Changeset detected

Latest commit: eb9cf06

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

[teemingc]

@benmccann I'm not sure if the adapter-auto case for Workers Builds is very useful with this PR because it doesn't "just work" like the other platforms do (since it fails without a Wrangler config file). Would it be useful to generate a basic Wrangler config during the Workers CI so that it just works? Or is it better that users get a deployment error which forces them to setup a wrangler.jsonc file?

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-13733-svelte.vercel.app/

[benmccann]

Ah, I guess the PR description is outdated then as it suggests it works without a config

What would a basic config contain? Is there anything we might accidentally omit or get wrong by doing that?

[teemingc]

Ah, I guess the PR description is outdated then as it suggests it works without a config

Yeah, I was half-way implementing the generated config but then wasn't sure if it would be a good idea.

What would a basic config contain? Is there anything we might accidentally omit or get wrong by doing that?

The minimum we would need would be:

{
	// `name` is not required since Cloudflare's dashboard requires the user to enter that before the build
	"main": ".svelte-kit/cloudflare/_worker.js",
	// this will be based on the current date
	"compatibility_date": "2025-04-24",
	"assets": {
		"binding": "ASSETS",
		"directory": ".svelte-kit/cloudflare",
	},
	// only required if the user uses `getRequestEvent()` asynchronously.
	// Enabling this doesn't add any polyfills like `nodejs_compat` does so it could be safe to always have this?
	// Otherwise we could only include it if we detect `getRequestEvent()` being used.
	"compatibility_flags": ["nodejs_als"]
}

Another question is: how should we generate the Wrangler config? There are currently two ways to do this:

1. Simulate a user's Wrangler configuration file.
   This is probably the easiest and means writing a new wrangler.jsonc if there is no user configuration file already.

2. Create a redirected Wrangler configuration.
   I'm a bit wary of using this method because if the redirected config exists, the Wrangler deploy and dev commands will always ignore the user's configuration file until the redirect is deleted. Fortunately, Wrangler does warn the user if the redirect config is being used. However, it would be better if we could create a config that acts as a fallback/override rather than a complete replacement. I've asked the Cloudflare team about this option and they recommended validating the user config instead.

[teemingc]

We can only progress on this once we start using the Cloudflare Vite plugin to automatically generate a wrangler config file https://developers.cloudflare.com/workers/vite-plugin/reference/programmatic-configuration/