Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zod 4

zod.dev

Post reply on HN
Print view View original

251–260 of 260 posts

Re: Zod 4

#251

Post by hdjrudni »

_1tem wrote: post #225
andrewingram wrote: post #222

Earlier quoted context omitted.

We have an enormous number of backend-only Zod schemas that are used as part of our data pipelines; so it doesn't seem like something that only exists to solve SPA problems.

If it’s backend only why do JSON shapes need to be continually checked? Can’t you serialize higher level classes or use the database?

Use the database? As in just throw user input straight into the DB without so much as checking its length to make sure it fits? Just let it error out? No sanitization, nothing?

Re: Zod 4

#252

Post by ts17631 »

colinmcd wrote: post #126
codeflo wrote: post #124

Earlier quoted context omitted.

Is there any advantage to this approach over publishing a separate "zod4" package? That would be just as opt-in and incremental, not bloat download sizes forever, and make it easier to not accidentally import the wrong thing.

Ecosystem libraries would need to switch from a single peer dependency on Zod to two optional peer dependencies. Despite "optional peer dependencies" technicall being a thing, its functionally impossible for a library to determine which of the two packages your user is actually bringing to the table. Let's say a library is trying to implement an `acceptSchema` function that can accepts `Zod3Type | Zod4Type`. For star…

Thanks a lot for zod and really looking forward to trying out the new version! Also as a primary Go developer this issue just has been really interesting to read about. Go avoids this issue by just not having peer dependencies and relying on the compiler to not bundle unused code - or just live with huge binaries when it doesn't work out :-)

I am still curious about the `zod4` idea though. Any thoughts on adding an `__api_version` type of property to distinguish on to all of zod's public types? Perhaps it's prohibitive code-size wise but wondering if it's possible somehow. Then downstream libraries could differentiate by doing the property check.

Just wanted to share the idea but the current state seems ok too.

Re: Zod 4

#255

Post by dalmo3 »

blackoil wrote: post #71
causal wrote: post #5

Zod is a lot better than some of the alternative solutions I've seen. That said, the need for this sort of explicit validation always felt like a failure of where modern web development has taken us. It's so frustrating how full-stack development requires so many ways of describing the same shapes: JS input validation, Swagger for API definition, server-side input validation, ORM for schema conformance, and TypeScrip…

We use drizzle + Hono + client with zod. So the entire chain from ui to client to server to DB follow same validation and shape.

How do you use the same validation for drizzle and zod? I have been writing duplicate schemas and hoping they match...

Re: Zod 4

#256

Post by enbugger »

The library pretty much remained unusable garbage without documentation comments. I have no idea why it became so popular and why this release is named "stable" when there is even no 4.0.0.

Re: Zod 4

#257

Post by mary-ext »

ssousa666 wrote: post #191
colinmcd wrote: post #125

Author here, AMA! Regarding the versioning: I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach. Ultimately npm is not designed to handle the situation Zod finds itself in. Zod is subject to a bunch of constraints that virtually no other libraries are subject to. Namely, the are dozens or hundreds of libraries that directly import interfaces/classes from Zod and use…

I saw your tweet about cracking type inference for recursive schemas. It seems like the solution to this problem is pretty straightforward and simple. Was the solution really as simple as using a getter, or is there some additional complexity that I am failing to grok?

the solution is to avoid TypeScript eagerly validating the object's value type. eager validation breaks cyclic references.

Re: Zod 4

#258

Post by mary-ext »

mary-ext wrote: post #257
ssousa666 wrote: post #191

Earlier quoted context omitted.

I saw your tweet about cracking type inference for recursive schemas. It seems like the solution to this problem is pretty straightforward and simple. Was the solution really as simple as using a getter, or is there some additional complexity that I am failing to grok?

the solution is to avoid TypeScript eagerly validating the object's value type. eager validation breaks cyclic references.

Zod's source code is a bit unwieldy to explain what's going on I feel, so here's a small validation library I wrote that uses the same principle

https://github.com/mary-ext/atcute/blob/596e023bcb490b16d09a...

Re: Zod 4

#259

Post by blackoil »

dalmo3 wrote: post #255
blackoil wrote: post #71

Earlier quoted context omitted.

We use drizzle + Hono + client with zod. So the entire chain from ui to client to server to DB follow same validation and shape.

How do you use the same validation for drizzle and zod? I have been writing duplicate schemas and hoping they match...

Drizzle has a zod addon, to generate zod schema from table defn. So table defn is source of truth, we mix generated zod schemas to get hono request validators. Same zod schema are also used on client to validate forms.
Post reply on HN