Support `exactOptionalPropertyTypes` for `partial` and `optional` helpers
See original GitHub issueHi!
Zod is adding the undefined
type to all keys that are optional when using the different .partial()
modifiers.
How about differentiating them by being present and undefined or just not present at all like typescript does with exactOptionalPropertyTypes: true
.
Would it be possible to implement in zod? I guess it could be the default since if you don’t care you don’t care. Also just using the typescript Partial
type will actually honor exactOptionalPropertyTypes
by default (on the type level that is).
Issue Analytics
- State:
- Created a year ago
- Reactions:3
- Comments:14 (5 by maintainers)
Top Results From Across the Web
TSConfig Option: exactOptionalPropertyTypes - TypeScript
With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on type or interfaces which have a ? prefix.
Read more >How to define a type from an existing type but with optional ...
The strictPartial() function is a curried function. It takes a two type parameters: T , the object type in question (with no optional...
Read more >optional vs. undefined - TkDodo's blog
Since Version 4.4, TypeScript has a compiler option called exactOptionalPropertyTypes that can help us distinguish a bit better between the ...
Read more >exactOptionalPropertyTypes : Partial of index signature adds ...
exactOptionalPropertyTypes strictoptionalProperties Partial index ... We don't support the notion of optional index signatures (i.e. it ...
Read more >The Definitive TypeScript 4.8 Guide - SitePen
Tooling support is where TypeScript really shines. ... we simply make the z property of the interface optional; the resulting type checking ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@zetaraku I think the problem is that while everything is fine type-wise when doing so, the code that runs at runtime need to know whether an explizit
undefined
value is acceptable. WhenexactOptional...
is enabled, the expected runtime behavior forkey?: number
would be to fail parsing when key exists, but is undefined. But the runtime does not know under which TS settings the code was compiled. This is why it appears to me there is no way to signal this intention to the runtime besides via a separate refinement function that has this behavior AND typing.Moving my complaint in https://github.com/colinhacks/zod/issues/1540 here, because it sounds like the same issue.
My specific problem is that I’m trying to parse values into this type:
The
bold
flag, if present, is always the valuetrue
. Example test cases:This schema is designed to work with Slate, and the values are in a database. The design is therefore non-negotiable.
I can’t figure out how to configure zod to make the
bold
property optional, without also addingundefined
to the type of the property. The.optional()
method seems to do conflate the two: it makes the property optional, but also allows the valueundefined
if present. For example,zod.parse
allows the value{ text: "foo", bold: undefined }
.I realize I could do this with
.refine()
, but then the constraint is not represented in the type system. I want the type of.parse()
to be{ text: string; bold?: true; }
.