Mismatch between Zod validators and transformed Date types

[alexanderhorner]

Context:
Using @hey-api/openapi-ts with @hey-api/transformers turns all format: date-time fields into Date in the generated TypeScript interfaces. Meanwhile, adding the Zod plugin ('zod') produces Zod schemas that still validate those fields as string rather than Date.

Problem:

• After a response is fetched, the transformer converts "2025-06-04T12:00:00Z" into a Date.
• If you then run the generated Zod validator (e.g. UserSchema.parse(userObj)), it expects userObj.createdAt to be a string, not a Date, causing a validation error.

Request:
Is there an existing way (or plan) in @hey-api/openapi-ts to generate two Zod schemas per model:

1. A raw schema (createdAt: string) for validating before transformation, and
2. A transformed schema (createdAt: Date) for validating after transformation?

If no such feature exists, what’s the recommended approach to keep Zod validators in sync with transformed types without writing two separate schemas manually?

[mrlubos]

Hey @alexanderhorner, yeah, this needs to be improved. Sorry for the trouble!

[mrlubos]

I think for one, it would be good to come up with the naming strategy for these. The same problem should be handled in types. It's on my radar for a long time, just haven't had time to prioritise it

[jamesarosen]

Some ideas

createdAt: string	createdAt: date
z{Foo}WireSchema	s{Foo}Schema
z{Foo}WireSchema	s{Foo}MemorySchema
z{Foo}SerializedSchema	s{Foo}DeserializedSchema
z{Foo}InertSchema	s{Foo}LiveSchema

It would also be great to expose the transforms between the two. Example use-case:

1. Backend API declares OpenAPI spec for getFoos, serialized dates to strings
2. Backend-for-frontend consumes OpenAPI spec, parses dates to Dates and performs some additional computation
3. BFF re-serializes dates to strings to send to the browser
4. Browser re-de-seriealizes dates to Dates for hydration

[alexanderhorner]

From those options I like serialized and deserialized the most, but I'm not sure if it's technically correct.

Also for compatibility it might be a good idea to leave the name of the transformed types as they are and only call the new types something else

[mrlubos]

Agree. Compatibility is one reason, but also it should work for people who don't use transformers. I don't want the final output change depending on your configuration, it should always be the same. The only thing changing will be the internals

[alexanderhorner]

Maybe User and RawUser, zUser and zRawUser?