[franciscop]

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.

[soulchild77]

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...

[franciscop]

> "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!