Repository navigation
Support serialized enum values with Zod-style schema normalization #465
Description
Follow-up to #69.
The TypeScript validator rejects valid serialized string-enum values such as "EUR", because it checks plain JSON literals against string-enum types. Literal unions, including an enum-derived ${CURRENCY} type, work.
Proposal
Use the enum-to-literal-union approach in the Zod schema generator (getZodSchemaAsTypeScript) as the basis for a JSON-facing normalization step for TypeScript enum schemas. Validate serialized member values while preserving the rest of the schema's checks.
Acceptance criteria
- Valid enum values pass; unknown values and member names that differ from their values fail.
- Cover nested objects, arrays, unions, and individual enum-member types.
- Preserve existing numeric-enum behavior and document the supported scope for computed members.
- Add regression tests and usage documentation.
Avoid blanket casts, diagnostic suppression, or executing schema code. This tracks native enum support separately from the documented workaround in #69.
Activity
robgruen commentedon Nov 6, 2026
/typechat reply
github-actions commentedon Nov 6, 2026
Your diagnosis matches the TypeScript validator: it generates an assignment of the JSON to the original schema type, so the plain string EUR is not accepted as a string-enum member. The Zod generator does emit enum values as a union of allowed literals, which is a useful representation pattern. Zod still validates through safeParse, so copying that representation alone is not a replacement for TypeScript validation.
yushiwuzhengjianyuzi already has an open pull request for this issue with recursive normalization, tests, and usage documentation. Continuing that contribution is preferable to a duplicate implementation. The string-union workaround from sho31's original report remains available; deriving the allowed strings from an enum avoids repeating the values, but does not preserve the enum's distinct type identity.
The existing review identifies two unresolved correctness problems. The recursive mapping can discard function and constructor signatures, potentially accepting JSON objects where those types are required, including inside promise-like types. The diagnostic change can also report missing properties from the wrong type when an application customizes createModuleTextFromJson, the hook that generates validation source code. Those findings directly affect your requirement to preserve the rest of the schema's checks. Resolving them in the existing pull request, while retaining your numeric-enum compatibility and computed-member documentation requirements, is the useful next step.
Related contributions: #471.
Automated response requested by the project owner. This does not accept work or authorize implementation.