feat: Validator (zod) definitions into OpenAPI schema

[dan-hale]

Describe the feature

I would like to propose an alternative way to sole issue #2974 by accepting a field on defineRouteMeta which can be parsed via custom processors (eg, z.toJSONSchema(schema)) and populated into openAPI global schemas.

Currently, there is no way to use a validator like Zod to define the structure of event handler inputs and re-use the schema in the OpenAPI definition within the route file itself. This is because defineRouteMeta is statically compiled, and therefor never sees the value. As a result, duplication of code is required in definitnng both a validator as well as a JSON schema.

Ideally there would be some way to export or define Zod (or other validators) objects in an event handler to automatically be converted into JSON Schema to define responses, request body and query params in OpenAPI via your validation code.

I would like to spark a conversation around ideal implementation for this. At minimum giving us a way to define objects into the global schema namespace would be helpful but not ideal.

Perhaps a better solution could be a new composable, such as defineSchema or defineValidation?

Looking forward to contributing for this once we have a clear direction.

Additional information

• [x] Would you be willing to help implement this feature?

[ilnytskyi]

Found the same issue after thinking about integrating elysiajs https://elysiajs.com/integrations/nuxt into nuxt api routes. Found it unclear how to handle elysiajs properly (probably via custom composable) and not to loose nuxt-native code convention like const { data } = await useFetch('/api/hello').

But then I discovered that nitro already has experimental openApi and one can define schema via defineRouteMeta and there is great scalar plugin, same as in elysia. So there is no need to integrate nuxt/nitro with foreign framework for this use case.

Also I found it impossible to write a code like this. So zod v4 https://zod.dev/json-schema seems to be unusable for this case. I see the only workaround is probably to build/compile zod types into files before using with openAPI.

const myResponseJSONSchema = z.toJSONSchema(myObject, {target: "openapi-3.0"});

defineRouteMeta({
    openAPI: {
        tags: ["test"],
        description: "Test schema description",
        responses: {
            200: {
                description: "Test route description",
                content: {
                    'application/json': {
                        schema: myResponseJSONSchema
                    }
                }
            }
        }
    },
});

That would be really great to use this with single source of types for

• validation
• defining types
• describing route request / response
• swagger generation
• other use cases where either toJSONSchema or their inferred types needed