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

191–200 of 260 posts

Re: Zod 4

#191

Post by ssousa666 »

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?

Re: Zod 4

#192

Post by bilalq »

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…

While publishing both versions together helps with compatibility issues, the library now becomes even heavier in environments where tree-shaking is not enabled. In React Native, for example, you have to jump through a lot of hoops to get tree-shaking to work (including getting off the default metro bundler, which can often be a non-starter).

Re: Zod 4

#194

Post by Dylan16807 »

rafram wrote: post #189
Dylan16807 wrote: post #170

Earlier quoted context omitted.

> I mean, it's probably fine if you're only ever getting your data from JSON.parse(). So 90% of use cases?

Sure, and then only 10% of your use cases contain easily exploitable vulnerabilities.

You use a different function than Validate_Parsed_JSON in those cases. But most typescript programs are only going to need JSON-compatible input. Maybe some XML but that's also going to have similar formulaic output from your parser.

If something can directly hand you a maliciously built data structure, you're probably designing your system wrong. Are you running untrusted javascript in the same interpreter? That's a very hard problem that should be avoided if at all possible.

Basically, only working on JSON.parse is something to document but it's not at all a weird restriction, or a reason to balk at putting it into production.

Re: Zod 4

#195

Post by nisten »

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…

TLDR: What do I put on my package json to get latest latest latest? "^4" ?

Re: Zod 4

#196

Post by chamomeal »

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…

You shouldn’t typically need to redefine your data all over the places. There are zillions of converters for everything to zod, and zod to everything.

If you already have JSON schema/swagger schemas, generate zod from em. If you use a typescript orm, I bet you $10 there’s a zod generator for it.

Honestly zod has gotten so popular that for me, it’s the unifying schema definition that everything else in the stack can rely on. And since directly defines the types, devs actually keep it up to date (swagger docs at my company are ALWAYS lagging behind changes)

Re: Zod 4

#197

Post by lenkite »

jauntywundrkind wrote: post #24
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…

TypeScript's insistence on being a static checking/compile time only system is such a sad wound to the whole ecosystem. I don't want TypeScript to be a runtime checker, but I want it to export useful usable type data for classes, functions, objects. TypeScript feels like the best source of truth we have, but instead so many of the attempts to reflect on what we have are all going it alone, having to define their own…

Hard agree - TSC already has this information, why should so many libraries in the world duplicate it ? A single source of truth works better than everyone repeating the same in different, finicky runtime validation libraries.

Re: Zod 4

#199

Post by colinmcd »

Lvl999Noob wrote: post #155
colinmcd wrote: post #122

Earlier quoted context omitted.

Author here. I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach. Ultimately you're right that npm doesn't work well to manage the situation Zod finds itself in. But Zod is subject to a bunch of constraints that virtually no other libraries are subject to. There are dozens or hundreds of libraries that directly import interfaces/classes from "zod" and use them in th…

Are there any plans of doing an actual v4 release and making zod/v4 the default there? Perhaps make simulatenous releases of zod v3 containing a /v4 path and a zod v4 containing a /v3 path? Then converge on just zod v4 with no /v3 from 4.1 onwards.

Yep, at some indeterminate point when I gauge that there's sufficient support for Zod 4 in the ecosystem, I'll publish `zod@4.0.0` to npm. This is detailed in the writeup[0]

[0] https://github.com/colinhacks/zod/issues/4371

Re: Zod 4

#200

Post by colinmcd »

kaoD wrote: post #163
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…

Sorry if it's mentioned in the article but I'm on mobile. Is fixing .optional() in TS[0] part of the 9/10 top-issues fixed? This has been my biggest pain point with Zod... but still Zod is so good I still choose to just deal with it :) Thanks for an amazing part of the ecosystem. [0] https://github.com/colinhacks/zod/issues/635

Yes! Zod now differentiates between `z.string().optional()` and `z.union([z.string(), z.undefined()])` (as in TypeScript itself). Details: https://x.com/colinhacks/status/1919291504587137496
Post reply on HN