[GH-ISSUE #195] Plan for bindings #46

New issue

Closed

opened 2026-05-06 12:36:48 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

2026-05-06 12:36:48 +02:00

Owner

Originally created by @jokull on GitHub (Feb 28, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/195

Is there a roadmap for making bindings available (D1, R2, etc.) in RSC? On my blog I'm doing direct drizzle stuff in RSC.

Originally created by @jokull on GitHub (Feb 28, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/195 Is there a roadmap for making bindings available (D1, R2, etc.) in RSC? On my blog I'm doing direct drizzle stuff in RSC.

BreizhHardware closed this issue

2026-05-06 12:36:48 +02:00

BreizhHardware commented

2026-05-06 12:36:49 +02:00

Author

Owner

@southpolesteve commented on GitHub (Mar 2, 2026):

Thanks for filing this! Good news: bindings should already work in server components today via the cloudflare:workers module import.

import { env } from "cloudflare:workers";

export default async function Page() {
  const result = await env.DB.prepare("SELECT * FROM posts").all();
  return <div>{JSON.stringify(result)}</div>;
}

We just verified that the build pipeline handles this correctly. The @cloudflare/vite-plugin runs the RSC environment in workerd, where cloudflare:workers is a native module. vinext doesn't interfere with the resolution. The import gets properly externalized in the production build so workerd resolves it at runtime.

No custom worker entry needed, no special configuration. Just import { env } from "cloudflare:workers" in any server component and your D1, R2, KV, AI, etc. bindings should be available.

The existing examples all predate this pattern (they use the older fetch(request, env) approach with custom worker entries), which is probably why it wasn't obvious that this works. We'll update the examples to show the modern pattern.

Are you seeing different behavior? If cloudflare:workers isn't resolving for you, let us know what error you're hitting and we can dig in.

@southpolesteve commented on GitHub (Mar 2, 2026): Thanks for filing this! Good news: bindings should already work in server components today via the `cloudflare:workers` module import. ```tsx import { env } from "cloudflare:workers"; export default async function Page() { const result = await env.DB.prepare("SELECT * FROM posts").all(); return <div>{JSON.stringify(result)}</div>; } ``` We just verified that the build pipeline handles this correctly. The `@cloudflare/vite-plugin` runs the RSC environment in workerd, where `cloudflare:workers` is a native module. vinext doesn't interfere with the resolution. The import gets properly externalized in the production build so workerd resolves it at runtime. No custom worker entry needed, no special configuration. Just `import { env } from "cloudflare:workers"` in any server component and your D1, R2, KV, AI, etc. bindings should be available. The existing examples all predate this pattern (they use the older `fetch(request, env)` approach with custom worker entries), which is probably why it wasn't obvious that this works. We'll update the examples to show the modern pattern. Are you seeing different behavior? If `cloudflare:workers` isn't resolving for you, let us know what error you're hitting and we can dig in.

BreizhHardware commented

2026-05-06 12:36:49 +02:00

Author

Owner

@jokull commented on GitHub (Mar 2, 2026):

Just didn't know about cloudflare:workers env shim! Thank you. An example will point us all in the right direction.

@jokull commented on GitHub (Mar 2, 2026): Just didn't know about cloudflare:workers env shim! Thank you. An example will point us all in the right direction.

BreizhHardware referenced this issue

2026-05-06 12:38:52 +02:00

[PR #46] [CLOSED] feat(cli): load .env files with Next.js precedence #266

BreizhHardware referenced this issue

2026-05-06 12:38:59 +02:00

[PR #70] [MERGED] fix(dotenv): load .env files with Next.js precedence #288