I'm very curious, I'm learning from both HonoJS and ElysiaJS about how to build a great next-generation library, and the thing that strikes me from Hono is that it seems it has integration for a lot of things, BUT you have to write a lot of manual code for those instead of "extending the base Hono" so to speak. For the `zod-openapi` example you gave, I'm looking at the docs and it seems there's no import in common from hono to hono/zod-openapi project:

    import { z } from '@hono/zod-openapi'
    import { createRoute } from '@hono/zod-openapi'
    import { OpenAPIHono } from '@hono/zod-openapi'

I would have expected/hoped things to be more integrated, e.g. you still do `import { Hono } from 'hono'` and then somehow you connect to this OpenAPI middleware. Any thoughts on this? Do you feel like moving from "base Hono" to use hono/zod-openapi you have to change how you do things? Another place I've seen this pattern is with the different edges, you have different import/exports, which I understand to certain degree but I still think a bit more could be done at the base library.

That's actually something I find a bit awkward, too. Especially, there was no way to re-use the global Hono error handler for all OpenAPI routes. I created an issue[1] with my suggested workaround and was told that that's the way to go. Maybe things are that way because `zod-openapi` was introduced later on. But I believe in the end it doesn't really matter that much as the code is clean and readable. :)

[1] https://github.com/honojs/middleware/issues/323#issuecomment...

> "in the end it doesn't really matter that much as the code is clean and readable"

The thing I'm worried about is the behaviour differences of having 2 different ways of importing things, exactly as it seems you found. That's valuable feedback, thanks!

Was looking to do this the same with Hono. Need a basic REST API. Possible for you to share your code?

> request/response validation

> beautiful OpenAPI browser

> end-to-end type-safety without any code-generation

That's a great sales pitch - I'd looked at Hono before but now I've opened all the links you mentioned and will try it out.

We are using a similar stack. I assume your client is located in the same repo as your server? That's a no-go for us, so we're planning on using the OpenAPI spec to generate a type-safe frontend client. I kind of wish it was as easy as using the RPC middleware, though.

In cases where the client needs to stay separate, we have had a good experience with Orval[1] to generate a fully-typed @tanstack/query client from our OpenAPI spec.

[1] https://orval.dev/