Switching to using zod-openapi from zod-to-jsonschema to solve things like definition?

[tonyxiao]

Related issue here samchungy/zod-openapi#181

zod-openapi seems to have much better metadata and openapi support. In particular it could be extremely helpful for things like re-using definitions across the API endpoints. Could we look into adopting it?

[LilyRose2798]

I've just pushed out a version on my fork with working zod-openapi integration if you're interested:
https://github.com/LilyRose2798/trpc-openapi
The only things I've found that don't work yet are using z.undefined() inside a tRPC request/response zod schema, and using .transform on tRPC output schemas (works on all other schemas though), but none of these are things I've needed yet so I haven't gone to the effort of getting them working.

[tonyxiao]

amazing! any usage differences?

[tonyxiao]

in particular how does it support openapi defs?

[LilyRose2798]

There aren't any major usage differences other than the few current compatibility issues mentioned above which you might need to work around depending on your schema. Headers are also now provided using a Zod schema so if you were using those you might need to change that. Other than those nothing should need to change about your definition. The request/response schemas used in the procedure definition are just passed to zod-openapi with minimal modification (just extracting out any fields needed for path/query params) which then creates the spec document, so all info set in the .openapi meta works as you'd expect, including using $ref and having the schema be extracted out/de-duplicated automatically.