Repository navigation
adapter-cloudflare@5.0.0 breaks deployment #13300
Description
Describe the bug
After upgrading to @sveltejs/adapter-cloudflare@5.0.0 deployments no longer work, the ./.svelte-kit/cloudflare now depends on ./.svelte-kit/output and cannot resolve external dependencies. (in my case @ts-rest/core).
Reproduction
Deployment using only ./.svelte-kit/cloudflare binaries: https://github.com/trakt/trakt-lite/actions/runs/12734910219/job/35493024100#step:5:68
Deployment with ./.svelte-kit/output unpacked: https://github.com/trakt/trakt-lite/actions/runs/12735478470/job/35494291485#step:6:68
Deployment with @sveltejs/adapter-cloudflare@4.9.0 output: https://github.com/trakt/trakt-lite/actions/runs/12735605634/job/35494549765#step:5:67
Logs
No response
System Info
System:
OS: macOS 15.1.1
CPU: (14) arm64 Apple M3 Max
Memory: 1.29 GB / 36.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.18.0 - ~/.nvm/versions/node/v20.18.0/bin/node
npm: 10.8.2 - ~/.nvm/versions/node/v20.18.0/bin/npm
bun: 1.1.30 - /opt/homebrew/bin/bun
Browsers:
Chrome: 131.0.6778.265
Safari: 18.1.1Severity
blocking an upgrade
Additional Information
No response
Reacted by Zoltan Peter Gaal , Seohyun Lee, Christian Wesselhoeft and Zoltán Gaál
Activity
teemingc commentedon Jan 13, 2025
As of adapter-cloudflare@5.0.0, SvelteKit no longer uses esbuild to bundle the build. This is because Cloudflare's Wrangler also bundles the worker code when you try to deploy the project. We don't want to duplicate the bundling process so we let Cloudflare handle it instead (less error prone).
You should probably adjust your project's GitHub workflows to upload/download the entire
./svelte-kitdirectory instead of just./svelte-kit/cloudflareso that Cloudflare can correctly bundle the files that the worker relies on that are outside the.svelte-kit/cloudflaredirectory. We can't copy the server files to that directory because they will be made public by Cloudflare Pages.vladjerca commentedon Jan 13, 2025
@eltigerchino I tried again including the entire build output (intially when I opened the issue I included only the
outputandcloudfaredirectories).As you can see in this run: https://github.com/trakt/trakt-lite/actions/runs/12756619076/job/35555130981#step:5:72
Publishing these binaries result in cloudflare erroring on external dependencies, I've temporarily reverted the upgrade (again) trakt/trakt-web#277.
teemingc commentedon Jan 14, 2025
I forgot, you probably need to have your
node_modulesfolder as well or else Wrangler won't be able to bundle the dependencies your code is referencing.vladjerca commentedon Jan 14, 2025
@eltigerchino this sort of defeats the purpose of a deployment pipeline.
We build our artifacts and deploy later (could be arbitrary time later...).
From where I come from a build artifact is deployable at any point in time...
vladjerca commentedon Jan 14, 2025
So I've been thinking, I can understand you guys want to skip the build step (conceptually) but then I believe that the adapter should at a minimum:
node_modulespackagesreferencedby the outputAlso can we please re-open this issue @eltigerchino I don't see this as resolved 😕
dil-zgaal commentedon Feb 2, 2025
I have the same issue.
I understand that some build task is now moved for wrangler, but in that case could wrangler provide a tool to bundle the build into a single package/dist folder, etc. ? A self contained artifact is quite essential for many pipelines where a (tested) artifact can be deployed any time (to any compatible environment).
revert cf adapter, see: sveltejs/kit#13300
teemingc commentedon Feb 3, 2025
It's possible to compile the
_worker.jsfile through thewrangler deploy --dry-runCLI command, but it might be better if we had a Wrangler API to bundle the worker for us.cc: @dario-piotrowicz @petebacondarwin @jamesopstad
As a workaround for now, you could install
wranglerand modify your build script like below and it should work:#13072 is related as that removes the custom bundle step too
nignucial commentedon Mar 13, 2025
At the very least, while waiting for a proper fix, is it possible to update the adaptor docs to point new comers into the right direction?
I imagine it can be very frustrating to follow the docs just to run into this issue without knowing any workaround. 😂
teemingc commentedon Mar 19, 2025
Sorry this took a while. I think I've found a pretty satisfying fix that uses existing Cloudflare Wrangler behaviour. You can try out the fix before it's released by installing the adapter:
There's an undocumented feature that allows us to write all server files to a
_worker.js/directory. This means we don't have to bundle it as a_worker.jsfile in addition to Wrangler's bundling (previous behaviour) and we get to keep all server files in the build output folder again.However, copying the build output and uploading it directly through the Cloudflare Pages dashboard does not work because it doesn't detect the
_worker.js/directory and bundle it.teemingc commentedon Mar 22, 2025
Had to revert the PR as the build output was still missing the server dependencies. To get a build artefact, we'd need to bundle the server dependencies in a way that doesn't cause all the issues we previously had. The safest way to do this would be to wait for Cloudflare to provide a Wrangler API to bundle everything as a single worker file. Or we could try to get the adapter to influence the Vite build and enable
ssr.noExternalto bundle the deps (which may or may not cause us to have the same issues as before).vladjerca commentedon Jun 4, 2025
Really looking forward to this being fixed, we just migrated our app to CF workers so upgraded to the latest adapter. Had to sadly do my deployment part of the CI step now to avoid this issue 😔