Closed wowczarczyk closed 1 year ago
I saw this post https://github.com/chrishoermann/zod-prisma-types/issues/79 and indeed utilizing the ****OptionalDefaultsSchema
types instead of the input types is a way to overcome this problem. Just not sure how elegant this is ;)
Also, I think that if the input types would not be typed explicitly as ZodType<...>
but rather by using the new satisfies ZodType<...>
operator it would solve this problem as well. Not sure how backward compatible that would be...
@wowczarczyk thanks for reaching out. I actually tried using the satisfied
keyword but there is a limitation of zod that a specific type annotation is needed when recursive types are used as stated in the docs. So sadly it is not possible to switch to this solution because prisma types heavily rely on recursion.
Hey, great library!
I am working on a T3 app and wanted to use this lib to reduce boilerplate for input types to tRPC mutations. I got stuck a bit with the need of merging two generated *Input types:
The generated types are explicitly typed as
ZodType
that does not seem to have the.merge()
function as it belongs toZodObject
. Any ways of circumventing this problem?