Auto OpenAPI (Swagger) response type generation based on handler function in hono?

[doteric]

Hello 👋

I've had a quick look at hono and it seems like a decent expressjs replacement, but I'm wondering if it would be possible to auto-generate openapi spec. For the request of course it has to be defined by a zod schema for example, but for the response I would like to infer the schema based on the TypeScript return typing of the handler function. Has anyone tried this before with hono or some other solution? Are there any ready to use solutions? I've done some auto generation of openapi based on typescript return types before, but it was far from good and I'm trying to find something more widespread and if not available then maybe think about building something like this that is also pretty simple.

All suggestions welcome.
Cheers

[lakubuDavid]

Hi, there are three tools mentioned in the Hono documentation:

• hono-docs is a good starting point. You points to your routes file in the config script and it infers the input and output schema. You can use either the CLI or the API; I mostly use this one as it feels more like a drop-in add-on.
• hono-zod-openapi functions like zValidator but with a syntax more oriented toward OpenAPI.
• zod-openapi is one I haven't tried yet. It considers both schema and route definitions with OpenAPI from the beginning.

[doteric]

Thank you @lakubuDavid 🙇

Looks like hono-docs is indeed more or less something that I was looking for, but it has a few annoying limitations (cannot properly group api routes that are separated across files to not have it all in one file. This can be kinda addressed via tags, but that means the extra need of defining each single route inside hono-docs config. Would be ideal if it could just extract all paths from a top-level Hono instance). It has very good potential though and I might actually consider using it. It seems like it's not used by many though, I wonder why.

As for hono-zod-openapi and zod-openapi, from my understanding it require defining the response schema statically which means it does not extract the typing based on the handler response type I guess? This is something I wanted to avoid actually.