TL;DR — Extracts the enum AST emitter out of the TypeScript plugin's export.ts into a dedicated enum.ts, simplifies the duplicate-key bookkeeping, and moves the empty-literalMembers short-circuit in the Zod v4 enum resolver into baseNode so custom resolvers also benefit.

Key changes

• Extract exportEnumAst into its own module — moves ~185 lines of enum emission out of shared/export.ts into shared/enum.ts, leaving exportAst to just dispatch.
• Collapse key resolution into a single pre-pass — replaces the two-step itemsWithAttempts + per-item resolveEnumKey callsite with a single resolveItemsWithKeys that returns { item, key } pairs.
• Factor out createSymbolMeta — removes three copies of the same { resource: 'definition', tool: 'typescript', ... } literal inside buildSymbolIn calls.
• Move Zod v4 enum empty-literals guard into baseNode — baseNode now returns unknownToAst({ type: 'unknown' }) when there are no literal members, so custom ~resolvers.enum get the same fallback as the default path.
• Default validated preset to enums: 'javascript' — dev/typescript/presets.ts now passes the typescript plugin as an object so the Zod validator side has matching enum constants to reference.

_{Summary ｜ 4 files ｜ 1 commit ｜ base: main ← fix/validators-enum-type}

Debug code left in the Zod v4 enum resolver

Before: baseNode computed items once and emitted the Zod node.
After: baseNode also queries a hardcoded resource ID and console.logs the result on every call.

The new querySymbol({ resourceId: '#/components/schemas/PermissionAction' }) + console.log(a) block (and the commented-out console.log(ctx.schema) below it) clearly belong to a local debugging session — the schema name is repo-specific to whatever spec was being inspected, the result is never used, and console.log is otherwise absent from this plugin tree. Drop the block entirely before un-drafting; otherwise every generated Zod schema using z.enum will emit a console.log at codegen time.

packages/openapi-ts/src/plugins/zod/v4/toAst/enum.ts

TypeScript enum extraction and key resolution

Before: shared/export.ts carried the full enum emitter inline and computed each item's duplicateAttempt separately from its final cased key, re-running toCase + the leading-digit underscore prefix per-iteration.
After: shared/enum.ts owns the emitter end-to-end; resolveItemsWithKeys produces { item, key } pairs in one pass; createSymbolMeta deduplicates the resource: 'definition', tool: 'typescript' boilerplate.

The behavior is preserved: resolveEnumKey({ duplicateAttempt: 0 }) deterministically produces the same baseKey that the old inline expression produced, the nameConflictResolver still receives the post-prefix key, and $.member / $.prop consume the resolved key in the same order. The minor cost is calling resolveEnumKey twice for duplicates (once to derive the base, once with the real attempt), which is negligible and worth the readability win.

packages/openapi-ts/src/plugins/@hey-api/typescript/shared/enum.ts · packages/openapi-ts/src/plugins/@hey-api/typescript/shared/export.ts

Empty-literals fallback hoisted into baseNode

Before: enumToAst short-circuited to unknownToAst when itemsNode produced no literal members, and enumResolver separately returned the untouched ctx.chain.current on the same condition.
After: baseNode performs the check itself and returns unknownToAst({ type: 'unknown' }), so a user-supplied ~resolvers.enum that calls ctx.nodes.base(ctx) gets the same fallback the default path used to get only inside enumToAst.

Worth confirming that no existing custom resolver relied on ctx.nodes.base(ctx) returning an "enum chain shape" specifically (the unknown chain is structurally a Zod expression and should slot into normal chain composition, but it's a behavior change for that surface).

packages/openapi-ts/src/plugins/zod/v4/toAst/enum.ts

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

TL;DR — Teaches the Zod validator plugin (v3, v4, mini) to reuse a TypeScript-emitted enum/const symbol via z.nativeEnum(...) / z.enum(...) when one exists, instead of always inlining literal members. Threads SchemaVisitorContext.path through every toAst entrypoint so the lookup can compute a resourceId, retires the walkerCtx field, and extracts the existing TS enum codegen into its own shared/enum.ts.

Key changes

• Reuse TS enum/const symbols in Zod validators — when @hey-api/typescript runs alongside Zod and emits a non-const enum or a const object for the same $ref, enumToAst now emits z.nativeEnum(Foo) (v3) or z.enum(Foo) (v4/mini) instead of repeating the literals.
• path replaces walkerCtx — every Zod toAst function and its Pick<...> option type now takes path directly, and BaseContext extends SchemaVisitorContext. walkerCtx: ctx call sites become path: ctx.path.
• exportEnumAst extracted — the TS enum emitter is split out of @hey-api/typescript/shared/export.ts into a new shared/enum.ts, with resolveItemsWithKeys consolidating the per-item duplicate-key bookkeeping into one pass.
• querySymbols() added to PluginInstance — companion to querySymbol() returning the full array; the three existing internal call sites switch over.
• dev:ts/dev:py watch scopes narrowed — tsx watch now only re-runs on relevant input/config/preset files instead of the entire monorepo.

_{Summary ｜ 57 files ｜ 1 commit ｜ base: main ← fix/validators-enum-type}

Test coverage gap for the new lookup path

Before: Zod plugin emitted inline z.enum([...]) / z.union([...]) literals regardless of co-plugins.
After: Zod plugin emits z.nativeEnum(TsEnum) (v3) or z.enum(TsConst) (v4/mini) when a TS symbol matches the same resourceId.

The Zod snapshot matrix under packages/openapi-ts-tests/zod/v{3,4}/__snapshots__/3.{0,1}.x/{mini,v3,v4}/ was not regenerated, and none of the existing scenarios co-load @hey-api/typescript. The new querySymbols branch is therefore unreachable from any test in this PR — existing snapshots stay green because the lookup always returns [] and the inline-literals fallback runs. Consider adding scenarios that combine @hey-api/typescript (with both enums: 'typescript-const' and enums: 'javascript' cells) and zod, so each of the three dialects produces a snapshot proving the z.nativeEnum(...) / z.enum(...) selection, mirroring the matrix symmetry the repo expects.

packages/openapi-ts/src/plugins/zod/v3/toAst/enum.ts · packages/openapi-ts/src/plugins/zod/v4/toAst/enum.ts · packages/openapi-ts/src/plugins/zod/mini/toAst/enum.ts

Ordering and SDK-validator path

The lookup assumes @hey-api/typescript has already registered its enum/var symbol by the time the Zod walker reaches the same $ref. With a user-supplied plugins array that lists zod before @hey-api/typescript, querySymbols returns [] and the inline literal fallback runs — silently — so the behavior degrades to today's output without any signal. Separately, createRequestSchemaContext and createResponseValidator* in all three api.ts files seed path: ref([]); nested walks inside an SDK validator layer therefore can never match a definition-scoped TS symbol. Both behaviors look intentional, but neither is documented, so future readers may chase phantom regressions.

packages/openapi-ts/src/plugins/zod/v3/api.ts · packages/openapi-ts/src/plugins/zod/v4/api.ts · packages/openapi-ts/src/plugins/zod/mini/api.ts

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}