Feature Request: First-class Cloudflare Workers adapter with Service Binding and Durable Object support

Feature Request

Summary

Add a dedicated Cloudflare Workers adapter for Elysia that goes beyond basic fetch handler compatibility — specifically supporting Service Bindings (direct Worker-to-Worker calls without HTTP overhead) and Durable Object stub injection into the handler context.

Current State

Elysia already runs on Cloudflare Workers via the generic fetch export pattern:

// works today — basic fetch handler
const app = new Elysia().get('/', () => 'hello world')
export default app

However, accessing Cloudflare-specific bindings requires awkward casting:

app.get('/kv', async ({ request }) => {
  // ❌ no typed access to env bindings in context
  const env = (request as any)._env as Env
  return env.KV.get('key')
})

Proposed API

// elysia-cloudflare-workers adapter (new package or built-in preset)
import { Elysia } from 'elysia'
import { cloudflare } from '@elysiajs/cloudflare'  // new

interface Env {
  KV: KVNamespace
  DB: D1Database
  ROOMS: DurableObjectNamespace
}

const app = new Elysia()
  .use(cloudflare<Env>())           // injects env + ctx into Elysia context
  .get('/kv/:key', async ({ params, cf }) => {
    const value = await cf.env.KV.get(params.key)   // fully typed
    return value ?? 'not found'
  })
  .get('/ws/:room', async ({ params, cf, upgrade }) => {
    const id = cf.env.ROOMS.idFromName(params.room)
    const stub = cf.env.ROOMS.get(id)
    return stub.fetch(cf.request)   // proxy to Durable Object
  })

export default app  // export as Workers module handler

Why This Matters

Elysia + Bun is a compelling combination for local dev, but the target deployment for many teams is Cloudflare Workers (edge, zero cold-start, global). A first-class adapter would make Elysia a strong alternative to Hono for Workers-based APIs.

Technical Notes

• Workers passes (request, env, ctx) to the fetch handler — the adapter needs to thread env and ctx into Elysia's DI system
• ExecutionContext.waitUntil and ExecutionContext.passThroughOnException should also be surfaced
• Compatible with wrangler dev local simulation

Would be happy to prototype an adapter package if the team agrees on the API shape.