Repository navigation
Detect the Cloudflare adapter with SvelteKit 3 - #1240
Conversation
SvelteKit 3 flattened its resolved config, so the adapter is at api.options.adapter instead of api.options.kit.adapter. The detection only read the old path and never injected the Workers env loader. Check both shapes.
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes Checked adapter detection, regression tests, documentation, and the patch release entry against SvelteKit's versioned upstream source; all 22 Vite integration tests passed after generating the parser grammar.
- Adapter detection: Supports SvelteKit 3's
api.options.adapterwhile retaining SvelteKit 2'sapi.options.kit.adapterand the existing Cloudflare loader behavior. - Regression coverage: Exercises loader injection for both configuration shapes and confirms non-Cloudflare adapters remain unaffected.
- Documentation and release: Clarifies SvelteKit 3's Vite-only configuration and includes a patch release entry for the Vite integration.
Validation used synthetic setup plugins and a mocked loader, not a live SvelteKit 3 build or Workers deployment.
gpt-6.1-sol | 𝕏
There was a problem hiding this comment.
No new issues found.
Reviewed changes Reviewed the delta since 70c5136, verified the setup plugin name against SvelteKit 3.0.1's source, and ran all 24 Vite integration tests successfully.
- Restricted flattened adapter detection: Required
vite-plugin-sveltekit-setupfor the SvelteKit 3 adapter shape, preventing unrelated plugins from shadowing detection while preserving the SvelteKit 2 lookup. - Added regression coverage: Tested an unrelated top-level adapter preceding SvelteKit and
adapter-autodetection withWORKERS_CI=1.
Validation used synthetic setup plugins and a mocked loader, not a live SvelteKit build or Workers deployment.
gpt-6.1-sol | 𝕏

SvelteKit 3 moved the resolved adapter from
api.options.kit.adaptertoapi.options.adapteronvite-plugin-sveltekit-setup.detectSvelteKitCloudflareTarget(added in #827) only read the old path, so on SvelteKit 3 the Workers env loader was never injected and nothing read the__VARLOCK_ENVbinding. It now reads both shapes.With SvelteKit 3.0.1 and
@sveltejs/adapter-cloudflare8.0.0,vite buildpreviously logged no detection notice and emitted an init-only SSR chunk. Now the notice is logged and the chunk reads__VARLOCK_ENV, as with SvelteKit 2.Adds unit tests for both shapes, and a docs note that SvelteKit 3 only supports the Vite config.
SvelteKit references, to check the shape change:
config.kit.*are now top-level.adapteris a top-level option in 3.0.1, and akitkey is rejected (L153). In 2.70.3 it lives insidekit.api.optionsin both versions.