Since v4.10.0, we always have to branch by status or ok to get the correct types in RPC (hc).

[baseballyama]

PR #4393 improved the ability to get accurate types for specific status codes. While this is a great improvement on its own, it is causing an issue in my project.

In my project, we centrally manage 4xx and 5xx errors using a customized fetch function. Our design allows individual UI components to handle only the success cases. Previously, this meant our UI components were type-safe without needing to explicitly check the response code.

However, since v4.10.0 (where #4393 was released), we can no longer resolve the types without checking status or ok in each UI component. As a result, we are forced to add these checks to every single API call site. This negatively affects the codebase by reducing readability (due to increased boilerplate) and increasing the bundle size.

Is there a way to maintain type safety without manually checking status or code, just as we were able to do before? Any advice would be appreciated.

[sunnypatell]

@baseballyama this is the expected consequence of PR #4393 (v4.10.0). the route schema now includes middleware error responses via MergeMiddlewareResponse in src/types.ts, so .json() returns a union of all possible response types instead of just the success type.

you don't actually need to branch by status everywhere. use InferResponseType with a status filter:

import type { InferResponseType } from 'hono/client'

// extracts only the 200 response type
type SuccessData = InferResponseType<typeof client.api.users.$get, 200>

or if you have a centralized fetch wrapper, type it to narrow automatically:

import type { InferResponseType, ClientResponse } from 'hono/client'
import type { SuccessStatusCode } from 'hono/utils/http-status'

async function fetchApi<T extends (...args: any[]) => Promise<ClientResponse<any, any, any>>>(
  fn: T, ...args: Parameters<T>
): Promise<InferResponseType<T, SuccessStatusCode>> {
  const res = await fn(...args)
  if (!res.ok) throw new Error(`API error: ${res.status}`)
  return await res.json() as InferResponseType<T, SuccessStatusCode>
}

the InferResponseType generic in src/client/types.ts already supports this status code filtering. related: #2719.

[baseballyama]

Thank you! But my use case is a bit more complex. Please see the details below for more details.

#4590

[sunnypatell]

@baseballyama thanks for the pointer to #4590, i see the gap now. InferResponseType<..., 200> solves the type extraction side but doesn't help with the call-site ergonomics when your custom fetch already guarantees success responses.

the core issue is that ClientRequestOptions['fetch'] doesn't let you parameterize the response type. so even if your fetch wrapper throws on 4xx/5xx, hono's types still force you to narrow.

a userland workaround that gives you both modes:

type SuccessResponse<T extends ClientResponse<unknown>> =
  T extends ClientResponse<infer D, infer S, infer F>
    ? S extends SuccessStatusCode ? ClientResponse<D, S, F> : never
    : never

async function api<T extends ClientResponse<unknown>>(
  res: Promise<T>
): Promise<SuccessResponse<T>> {
  const r = await res
  if (!r.ok) throw new Error(`API ${r.status}`)
  return r as any
}

// default: success-only types
const data = (await api(client.users.$get())).json()

// explicit: full union when you need 400 body
const raw = await client.users.$post()
if (!raw.ok) { /* handle validation errors */ }

the real fix would be making hc's custom fetch generic over the response type, so the type system knows your wrapper strips error responses. that would need a change in hono's client/client.ts though.