Is there a native enum (z.nativeEnum) support for zod pluggin?

[volkankalin]

Hello,

I am using the @hey-api/openapi-ts code generator alongside the zod plugin to create runtime validation schemas from my OpenAPI specifications.

By default, when encountering enums in the OpenAPI specification, the Zod artifacts are generated in array-based union format:

export const zStatus = z.enum(['active', 'inactive', 'pending']);

My question is:
Is there native support (or an existing configuration flag) to compile these schemas using Zod's z.nativeEnum() format instead?
Ideally, I would like to link the generated Zod schema directly to a generated TypeScript/JavaScript runtime enum:

// What I am trying to achieve
export enum Status {
  Active = 'active',
  Inactive = 'inactive',
  Pending = 'pending'
}

export const zStatus = z.nativeEnum(Status); // or `z.enum(Status)` for zod v4

If this feature does not exist yet, would you accept a PR adding a configuration option (such as enums: 'native') inside the zod plugin configuration block?

[dosubot[bot]]

Hi @volkankalin! I'm Dosu and I’m helping the openapi-ts team.

There's currently no built-in configuration flag (like enums: 'native') to generate z.nativeEnum() schemas in the Zod plugin. By default, the plugin outputs z.enum() for OpenAPI enums [1].

However, you can customize enum generation using the Resolvers API via the ~resolvers option [2]. This lets you override the default enum generation logic. For example:

{
  name: 'zod',
  '~resolvers': {
    enum(ctx) {
      // Custom logic to generate z.nativeEnum() instead
    }
  }
}

This gives you full control over how enums are compiled, though wiring it up to reference a separately generated TypeScript enum declaration would require some additional work on your end.

As for a PR — that's a question for the maintainers, but the resolvers escape hatch might unblock you in the meantime.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[mrlubos]

@volkankalin Hey! What @dosu said, I'm quite certain you'd be able to work around it today. Also open to a pull request if you want!

[mrlubos]

@volkankalin sounds about right. Feel free to open a pull request fixing either of these. I think there should be an enum feature in the Zod plugin the same way we have it in TypeScript and that would do this linking behind the scenes

[mrlubos]

@volkankalin fyi I'm looking into this for you. There are a few interesting design challenges to solve so I took it on

[volkankalin]

@mrlubos Thank you! While I am not very familiar with the repo, I would be happy to help however possible

[mrlubos]

@volkankalin you can follow along on #3884. Once merged, it will be available at @next. There are too many concepts to explain before you'd be able to contribute this yourself so I tackled it. It's mainly due to the aforementioned design deficiencies – if it was a matter of extending existing patterns, I would've let you do it. In the meantime, I'd love if you have any other feedback