asteasolutions
zod v4 support
running with zod v4 will failed with
@asteasolutions/zod-to-openapi/dist/index.cjs:48
const result = zodModifier.apply(this, args);
^
TypeError: Cannot read properties of undefined (reading 'apply')
v4 now support meta & jsonschema, this may make zod-to-openapi easier
linking my Zod 4 PR so people can find this tracking issue: https://github.com/colinhacks/zod/pull/4074
@colinhacks first of all cudos on everything you've done in V4. On the topic, sadly we've been very busy lately and never got the chance to start working on this. I did manage to startup the project using v4 today but it would require a lot of development to make things actually work as they did before. I know in your posts you've mentioned a 6-8 weeks until go-live. Do you have a date in mind? Just trying to figure out what our next steps might be
Hi @AGalabov !.
We are also working on some things to support Zod v4. We can refer to the "For library authors" section of the Zod documents:
https://v4.zod.dev/library-authors
The v4 will be released today or tomorrow, right? @colinhacks
I know you are busy, but if the zod-to-openapi supports v4, we can work on about Zod OpenAPI. BUT, you don't hurry!
I am right now implementing zod 3 and zod-to-openapi in our companies codebase and looking to upgrade to Zod 4 once an openapi conversion solution is ready.
If you guys need any help from a slightly above-average typescript coder, let me know :)
@yusukebe zod supports toJSONSchema natively now, which means for openapi 3.1 which it’s compatible with JSON schema, no external dependencies needed and just zod itself is enough.
@valerii15298 you are correct on that. There are lots of cases that would be covered by zod itself when it comes to basic schemas. However things like:
- Schemas in parameters
- Automatically linking extended schemas
- Anything to do with actual endpoints - i.e path, params, query, body registration cannot be dune with pure zod (and correctly so).
As for everyone here. I am trying to squeeze in extra time to work on this. This is the PR that I'd be working on. As of right now I've got to 162 out of 213 working tests. It is a relatively quick process but there are some things to figure out based on the new structure of zod's internals.
I'll keep you posted
Beta version is here!
All tests pass
There is still stuff to be done but I've released a beta version: 7.3.1-beta-zod-v4-2 available in npm. We can use that for testing
Just tryed to convert one of my projects, everything seem to work so far.. the lazy problem is still here tho :( :
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason: UnknownZodTypeError { message: 'Unknown zod object type, please specify typeand other OpenAPI props usingZodSchema.openapi.', data: { currentSchema: { type: 'lazy', getter: [Function (anonymous)] }, schemaName: undefined } }
@dr1ss I am glad to hear that! And yes we've not worked on the support for z.lazy at all
I converted our codebase to zod v4 (3.25.30) and zod-to-openapi v7.3.1-beta-zod-v4-2.
There seems to be an issue with discriminated unions and .extend(). This is a minimal reproduction:
This zod code:
const BaseTestSchema = z.object({
type: z.literal('CALCULATION_RESULT'),
calculation_type: z.enum(['LUMPSUM', 'MULTIPLY_BY']),
});
const CalculationResultSchema = z
.discriminatedUnion('calculation_type', [
BaseTestSchema.extend({
calculation_type: z.literal('LUMPSUM'),
}).openapi('CalculationResultLumpsummy'),
BaseTestSchema.extend({
calculation_type: z.literal('MULTIPLY_BY'),
}).openapi('CalculationResultMultiplyy'),
])
.openapi('CalculationResultSchema');
Results in this openApi result, where the discriminator is not correctly set:
CalculationResultLumpsummy:
type: object
properties:
type:
type: string
enum:
- CALCULATION_RESULT
calculation_type:
type: string
enum:
- LUMPSUM
required:
- type
- calculation_type
CalculationResultMultiplyy:
type: object
properties:
type:
type: string
enum:
- CALCULATION_RESULT
calculation_type:
type: string
enum:
- MULTIPLY_BY
required:
- type
- calculation_type
CalculationResultSchema:
oneOf:
- $ref: "#/components/schemas/CalculationResultLumpsummy"
- $ref: "#/components/schemas/CalculationResultMultiplyy"
discriminator:
propertyName: type # incorrect, should be calculation_type
mapping:
CALCULATION_RESULT: "#/components/schemas/CalculationResultMultiplyy"
Looks like it somehow is not correctly using the discriminator and falling back to... the first property maybe?
And now an "official" and stable beta version is here!
After active discussions on #301 I believe we've reached a good enough point where the code does match the quality that we want. There is now an official beta version: 8.0.0-beta.2 available in npm.
Anyone can use the latest beta version using:
npm install @asteasolutions/zod-to-openapi@beta
The plan is to use this for a while. Merge the PR. See if any outstanding issues popup and track them as separate issues (and PRs) and eventually release this as an official "latest" version.
Hello, thanks for this new version.
I'm in the process of upgrading to v4, but looks like you are using zod/v4 so I'm wondering if zod/v4-mini would be supported ?
In my use case, I want to have tree-shaking as my zod definitions are also used in client side. Hence, I maintain a separate registry which can be remove client-side via tree-shaking.
I am mainly using the OpenApiRegistry, and I'm looking for a way to use the zod registry as param to retrieve metadata from.
Do you have any suggestions ?
For cross reference, here is a draft PR trying to implement support of zod-mini https://github.com/asteasolutions/zod-to-openapi/pull/315
