-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
feat: support custom worker output path for easier integration of cloudflare worker handlers #14029
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: support custom worker output path for easier integration of cloudflare worker handlers #14029
Conversation
Introduces a new 'workerScriptPath' option to AdapterOptions, allowing users to specify the output directory for the worker script. The implementation prioritizes this option over the 'main' field in the wrangler config, providing more flexibility in worker script placement.
🦋 Changeset detectedLatest commit: 343627b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
|
Thanks for the PR! Just a heads up that we're exploring a similar route in #14008 which should allow users to specify their own worker and import a request handler from SvelteKit. This follows the same integration pattern which Remix uses with Cloudflare's Vite plugin |
Appreciate you sharing that, and #14008 looks like a solid approach! Thanks for all the work you're putting into it, looking forward to seeing it land. |
Eliminates the workerScriptPath option from AdapterOptions and related logic in the Cloudflare adapter. The worker script path is now determined solely by the wrangler config or defaults, simplifying configuration.
Removed documentation for the deprecated `workerScriptPath` option and added guidance on defining a custom Worker entrypoint for Cloudflare Workers. The new section explains how to wrap the SvelteKit handler and configure Wrangler to use a custom entry file, streamlining the process for adding additional Worker handlers.
The fetch function in the Cloudflare Worker example now explicitly returns a Promise<Response>, improving type safety and clarity in TypeScript usage.
|
I created an example sveltekit project with Durable Object using this pull request package with minimal code changes. Check this commit: BattlefieldDuck/sveltekit-durable-object-example@02b56e8 |
closes #13692
closes #10117
closes #1712
This PR allow users to specify the output path for the generated worker script. This option takes precedence over the
mainfield in thewranglerconfig, enabling more flexible integration with custom Cloudflare Worker handlers.The Problem
Currently,
@sveltejs/adapter-cloudflareoutputs the compiled worker to.svelte-kit/cloudflare/_worker.js, and this is hardcoded as the entrypoint via themainfield inwrangler.jsonc. This setup makes it difficult to extend the Worker with custom handlers (e.g.,fetch,queue,scheduled, etc.) since the generated file isn't easily imported or wrapped.After this PR
With this change, you can override the default worker script path and use your own file (e.g.,
src/worker.ts) as themainentry in thewranglerconfig, allowing for easier extension and composition.Example setup
Update
wrangler.jsonc:{ "name": "<any-name-you-want>", - "main": ".svelte-kit/cloudflare/_worker.js", + "main": "src/worker.ts", "compatibility_date": "2025-01-01", "assets": { "binding": "ASSETS", "directory": ".svelte-kit/cloudflare", } }Create
src/worker.ts:You can now extend this file with additional handlers, just like a standard Cloudflare Worker script. For example, you can add
queue,scheduled, or custom logic before or after callingsv.fetch().✅ Result
src/worker.ts).fetch,queue,scheduled, etc.Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.Edits