4 of 6 standards met
When using to enable extraction in , the value is included verbatim as an property in the generated entries. This is not a valid JSON Schema keyword in Draft 2020-12 (or Draft 7). Draft 4 used (no dollar sign) Draft 6+ renamed it to , and must be a URI-reference So the current behavior produces output that is either: An unrecognized keyword (Draft 2020-12 / Draft 7), or A non-URI value for a URI field (if interpreted as Draft 4 ) Reproduction Actual output Expected The key should either: 1. Be omitted from the JSON schema output (it's only needed internally for naming the key), or 2. Be emitted as with a proper URI value Option 1 seems cleanest since the key already serves as the identifier via .
Considering an optional email text input: from user perspective I think the appropriate validation for this would be which allows either or a valid email. In , these types of inputs are almost never undefined. In fact, optional fields are considered empty strings. What is the common way to achieve validating these type of fields correctly with zod? I have tried things like or , which felt a little unintuitive for a simple, yet very common optional field value. I was hoping for either a configurable type that could allow empty strings as well or a dedicated empty type for a string. Anyway, thank you for this great validation library, happy to help in any way!
Repository: colinhacks/zod. Description: TypeScript-first schema validation with static type inference Stars: 42045, Forks: 1833. Primary language: TypeScript. Languages: TypeScript (88.8%), MDX (9.9%), HTML (0.7%), JavaScript (0.4%), CSS (0.2%). License: MIT. Homepage: https://zod.dev Topics: runtime-validation, schema-validation, static-types, type-inference, typescript. Latest release: v4.3.6 (1mo ago). Open PRs: 99, open issues: 164. Last activity: 2w ago. Community health: 71%. Top contributors: colinhacks, JacobWeisenburger, scotttrinh, jeremyBanks, igalklebanov, samchungy, tmcw, alexxander, noritaka1166, dependabot[bot] and others.
TypeScript
Last 12 weeks ยท 91 commits
Summary This PR adds comprehensive documentation for a common type inference issue when using union types in Zod object schemas. Problem When using union types in object schemas, TypeScript infers an unexpected intersection: Root Cause This is not a Zod bug but a TypeScript type inference limitation with mapped types and union types in object properties. Solution This PR provides: 1. Documentation () Explains the issue clearly Provides 4 different solutions Best practices for avoiding this issue 2. Example Code () 6 complete workaround solutions Utility types: , , Test cases demonstrating all approaches 3. Analysis () Detailed technical analysis Comparison of solution options Implementation notes Solutions Provided 1. Type Assertion - Quick fix for immediate use 2. Utility Type - removes undefined from union 3. Schema Reuse - Reuse standalone schemas (recommended) 4. Helper Type - for property extraction 5. Schema Merge - Use for complex objects 6. Explicit Interface - Define interface first, then schema Files Added User-facing documentation Complete code examples Technical analysis (for maintainers) Impact No breaking changes - Documentation only Helps users - Provides immediate workarounds Reduces issues** - Clear documentation prevents duplicate issues Related Issue Fixes: #2654 /claim #2654