-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Cloudflare support for Vite #8531
Conversation
🦋 Changeset detectedLatest commit: 132fc21 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
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 |
Exciting 🙌 does the build target workers or pages? Or can we choose the build target? Thanks! |
Pages. CF core team flagged that Workers is now deprecated since Pages now is able to do everything Workers could do |
@pcattori I would like to try this on my own website since I deploy to CF Pages, how could I do it? Would it be enough if I use patch-package to patch the Vite plugin to include the changes here? |
@pcattori thanks for highlighting "do not use Worker Sites for new projects". We have a production app using Sites and I'd love to adopt Vite without having to also switch to Pages. It's clear we'll need to eventually but that prerequisite pushes Vite so much further away. Would supporting Workers and Pages be a lot of extra work/complexity/etc? Perhaps Workers could be supported for some bridge period then removed later? |
@sergiodxa I'll include instructions for trying things out once its in a good state for that. Right now there are a couple pieces missing. @jfsiii I haven't looked into how much work supporting CF Workers would be. There's a decent chance that this work will already support CF Workers but not something we test for right now, so would love feedback from y'all if you try it out. |
6da77a9
to
3e41c29
Compare
CF merged the |
const build = async (): Promise<ServerBuild> => { | ||
// eslint-disable-next-line @typescript-eslint/ban-ts-comment | ||
// @ts-ignore | ||
// eslint-disable-next-line import/no-unresolved | ||
return import("../build/server"); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting type-safe access to the build has come up a couple times.
@markdalgleish I'm tempted to design a getBuild
API that returns Promise<ServerBuild | undefined>
to avoid this ugly boilerplate. Server bundles complicate things slightly, though we could just return undefined
when server bundles are present.
const build = getServerBuild()
if (!build) throw Error("gotta run `remix vite:build` first!")
export onRequest = createRequestHandler({ build })
Plus this means you can change your output dir in vite.config.ts
without needing to update code in server.ts
or other scripts that rely on its location.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Writing the above snippet made me think that we should just include the throw Error
part within getServerBuild
and return Promise<ServerBuild>
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, this is something we can consider after Vite is stabilized.
Since the bindings are set automatically, will context.env get correct types for the bindings? Like context.env.MY_KV bring a KVNamespace? Or we will need it still override AppLoadContext? |
"@remix-run/cloudflare": "*", | ||
"@remix-run/cloudflare-pages": "*", | ||
"@remix-run/react": "*", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently Remix includes @remix-run/node
in optimizeDeps
but this template doesn't have direct dependency on it. This might cause Vite's warning for non-flat node_modules like pnpm where @remix-run/node
is not visible from root project.
I have a similar case where I use @remix-run/server-runtime
directly without @remix-run/node
and I've seen this warning on startup:
Failed to resolve dependency: @remix-run/node, present in 'optimizeDeps.include'
I'm not sure what's the best way to avoid this within Remix (also knowing that the necessity of this optimizeDeps
might be only for non-standard setup during tests), but for now, what I did was to exclude manually by custom plugin config
hook https://github.com/hi-ogawa/demo-remix-unstable-vite-cloudflare-workers/blob/2bdd6a4e15dc99584aa23897a5c1a40d7b185f6e/vite.config.ts#L15-L17
The bindings are defined in a TOML file ( |
How do I access the D1 database? Am i supposed to make wrangler file or pass it through wrangler dev --d1 flag.... |
The 🚨 As of today, the latest stable version of |
@pcattori cf pages doesn't support toml file you said.. but the movie demo which Ryan launched uses toml file and it works fine and he applied migration that are visible in local db also.. but i think as you said.. toml doesn't work and the latest remix and cloudflare is kind off broken.. when i apply migration. The changes is not reflected in local db even after passing flags and creating a toml file as recommended by cf docs.. i wanted to know.. there's no server file in app dir.. how is streaming handled.. also.. i wanted to setup this locally with binding for my project just to see and work and play around.. even if it's beta.. how can I set up like . Thanks for your work |
CF core team mentioned that CF pages reading from @cloudcreatr good questions, but to keep this conversation focused on the changes introduced in this PR, please ask any follow-up questions about how CF + Remix generally works in our Discord. Thanks! |
9e2f7bc
to
c8513a3
Compare
<docs-warning>Note that Cloudflare is not yet supported when using Vite.</docs-warning> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😍
|
||
# Wrangler | ||
remix vite:build # build app before running wrangler | ||
wranger pages dev ./build/client |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be 'wrangler'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is using wrangler
via wrangler pages dev
, not sure I understand your question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo wranger
instead of wrangler
😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh now I see it 😅 yep you're right
Am I doing something stupid, or is running it in dev via
|
@tsteckenborn Can you provide a repro in stackblitz? My guess is that something is not playing nice with |
What's the recommended way to customize the For example I was attaching this cache adapter on each request: https://github.com/AdiRishi/cachified-adapter-cloudflare-kv Should I create a custom server for dev mode and edit the getLoadContext in the catch-all route for prod mode? Or create an entry.server.ts file? Update: For prod mode I solved as above. For dev mode, I ended up modifying the adapter in vite.config, but it feels like like I'm not supposed to be able to do this. Also I can't add any per-request properties to the context this way: export default defineConfig({
plugins: [
remix({
adapter: async () => {
const { viteConfig, loadContext } = await cloudflare()();
const env = loadContext.env; // KVDATA, D1DATA
const ctx = {
...env,
CACHIFIED_KV_CACHE: cloudflareKvCacheAdapter({
kv: env.KVDATA as any,
}),
drizzle: createDrizzle(env.D1DATA),
executionCtx: {
waitUntil() {
// no-op
},
passThroughOnException() {
// no-op
},
},
};
return {
viteConfig,
loadContext: ctx,
};
},
}),
],
}); |
@patdx there's still a couple things to figure out for a general way |
🤖 Hello there, We just published version Thanks! |
@pcattori would be nice if this exposed both This would be great for monorepos where the wrangler.toml and persisted data might live in the parent/root dir, which is not necessarily the same dir as vite.config.ts |
🤖 Hello there, We just published version Thanks! |
... solved. Issue was in front of the keyboard. |
This currently relies on
wrangler@beta
, so let's wait to merge this until the next stable release ofwrangler
that includesgetBindingsProxy
. CF core team says that should happen next week or so.Usage
The
cloudflare
adapter reads bindings fromwrangler.toml
and sets them on theenv
field of load context:TODO
build
script:ssr
conditions as part of adapter API