Bun adapter does not pass server to Hono `fetch`

[ambergristle]

Describe the feature

the bun adapter only provides the Request argument to fetchHandler. as a result, when using with hono + bun, the hono Env isn't being populated with the bun server.

hono's fetch function accepts the bun server (or cloudflare env) as an optional second argument: https://github.com/honojs/hono/blob/790c57baa24b628a37b95025a8d41b1911b99d5d/src/hono-base.ts#L475

locally, passing the server as a second argument resolves the issue:

return fetchHandler(request, server);

neither the bun nor cloudflare adapter passes the server/env. i expect that for cloudflare apps, the env import can be used instead, but i'm not aware of an equivalent for bun.

i'm really enjoying using srvx (via vike), but the inability to access the server is a blocker. currently i'm trying to get the remote info. i see that the remote ip is added to the request, but the other Bun.SocketAddress properties are omitted, and it's necessary to brute-force the type safety when consuming via hono Context:

import type { Context } from 'hono'

const exampleHandler = async (c: Context) => {
  const ip = 'ip' in c.req.raw && typeof c.req.raw.ip === 'string'
      ? c.req.raw.ip
      : null
}

it seems like an easy fix, and i'm happy to open a PR to address, but i understand that there may be downstream consequences i'm unaware of. i appreciate your consideration, and thanks for a great library!

Additional information

• Would you be willing to help implement this feature?

[pi0]

The second argument of the fetch handler is never standarized (1). Bun passes server as second, cloudflare passes env, etc.

Srvx passes them in namespaced request.* extensions (docs), and it should work in hono too (only types are missing)

I had been talking with @yusukebe, it would be awesome if Hono would adopt req extensions as a convention, we can solve it universally!

---

(1)

// Fetch Standard (client)
(request: Request | URL, options?: RequestInit) => Promise<Response>

// Deno server
(request: Request, info: Deno.ServeHandlerInfo) => MaybePromise<Response>

// Bun server
(request: Request, server: BunServer) => MaybePromise<Response>

// Cloudflare Workers and Hono fetch
(request: Request, cfFnv: unknown, cfContext: ...) => MaybePromise<CFResponse>

[yusukebe]

Ah, request.runtime?.name? is a good idea!

[yusukebe]

Or like this?

(request: Request, runtime: RuntimeInfo ) => MaybePromise<Response>

For examples:

// Deno
(request: Request, deno: Deno.ServeHandlerInfo) => MaybePromise<Response>

// Bun
(request: Request, bun: BunServer) => MaybePromise<Response>

// Cloudflare Workers or fetch
(request: Request, env: {}, context: {} ) => MaybePromise<CFResponse>

[pi0]

request: Request, runtime: RuntimeInfo

We can pass basically same req.runtime ({ cloudflare: {}, deno: {} }) as second param too if it is more ergonomic for hono to adopt!

I am little bit more twards keeping everything under Request so we can also think about cross-compatibility extensions like req.ip and req.waitUntil without needing users/frameworks to check on each vendor's variation. (it also helps to carry whole context with one reference)

[ambergristle]

thanks for the clarification @pi0! i got a bit lost in the weeds figuring out what vike is doing under the hood. is something like this what you had in mind? it meets my current needs.

declare global {
  interface Request {
      runtime: {
        bun: { server: Bun.Server<undefined> }
      }
    }
}

import type { Context } from 'hono'
const getBunServer = (c: Context) => {
  return c.req.raw.runtime.bun.server
}