4 of 6 standards met
I’m trying to build the options array for programmatically from an object map, but I’m running into typing / usage issues. Given something like: I’d like to know: 1. What is the recommended / idiomatic way in Zod (v4) to use map (or similar) to build the options array for z.discriminatedUnion? 2. Is there a supported pattern (or helper) for turning a mapped array into the tuple type that z.discriminatedUnion expects, when the options are generated from an object like sensorsTypeProtocols? 3. If my approach is fundamentally flawed, what would be the suggested alternative for this “object map → discriminated union” use case? I’ve read the discriminated union docs, but they only show inline literal arrays/tuples of schemas, not generated ones. Related : https://github.com/colinhacks/zod/issues/3989 https://github.com/colinhacks/zod/discussions/2959 Thanks!
Hi, I’m the author of zod-schema-faker. I’m exploring a feature to narrow fake data by chaining schemas via registry metadata. The proposed usage might look like this: Since the type seems to replace only and , I haven’t been able to figure out how to make the fake meta type-safe: https://github.com/colinhacks/zod/blob/5bfc8f269a81d9edc283e7920868161e4129fb23/packages/zod/src/v4/core/registries.ts#L9-L24 I’m wondering whether there is a way to obtain , or if it would be possible to add support for this. Thank you for your consideration.
Repository: colinhacks/zod. Description: TypeScript-first schema validation with static type inference Stars: 41993, Forks: 1827. 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: 91, open issues: 162. Last activity: 1w ago. Community health: 71%. Top contributors: colinhacks, JacobWeisenburger, scotttrinh, jeremyBanks, igalklebanov, samchungy, tmcw, alexxander, noritaka1166, dependabot[bot] and others.
TypeScript
Last 12 weeks · 94 commits
This pr tries to fix the inferred types when using implementasync functions for interface implementations. I am uncertain if my fix was the "correct" fix but essentially this fixes the second issue described here https://github.com/colinhacks/zod/issues/5459. Now it's still unclear to ma as to why this used to be typed as a MaybeAsync and not a Promise. I assume I am missing some context and by that I also think that there must be something wrong with the change I have done but can't immediately see what. There were no tests indicating what the behavior should be as well I also wonder why it's only an issue when using the transform function and otherwise it is not. Another thing I'm wondering is if the output is already types as Promise, should the type still do Or should we check if already extends so we don't get in edge cases.