Specify type in custom error responses with @hono/client

[wyrd-code]

I'm using custom errors to simplify and standardize formatting of responses returned to the client. An example is the validation error below.

export class ValidationError extends HTTPException {
  constructor(public message: string) {
    super(422, {
      message,
    })
  }
}

I can then throw a validation error and not worry about specific status codes, and later also add specific validation messages that specify which fields were invalid in a POST request for example, and display those at appropriate places in a client side form.

This is used with a custom onError handler:

.onError(async (error, ctx) => {
    const status = 'status' in error && error.status || 500
    return ctx.json({
      message: error.message,
    }, status)
  })

When used with hono/client, the response I receive is typed as successful response and does not allow for a body type adjusted to the error version.

    it('will error for unknown email', async () => {
      const response = await client.auth['sign-in'].$post({
        json: {
          email: 'UNKNOWN_EMAIL@asgard.org',
          password: 'anything',
        },
      })

      expect(response.status).toBe(422)
      const body = await response.json()
      expect(body).toBe({
        message: 'Invalid email & password combination'
      })
    })

Typescript will show an error for the code above, saying Object literal may only specify known properties, and 'message' does not exist in type ....

Is there a way I could customize the ClientResponse type based on the status code, so that it understands there is a successful and a failed response? It's really ugly having to write body as xy all over the code.

Thank you

[yusukebe]

@wyrd-code

What you want to do is interesting.

Is there a way I could customize the ClientResponse type based on the status code, so that it understands there is a successful and a failed response? It's really ugly having to write body as xy all over the code.

Currently, it does not support status code. To support it, we have to change the code drastically; we can't do that immediately. But it can be a feature request.