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

161–170 of 260 posts

Re: Zod 4

#161

Post by hombre_fatal »

punkpeye wrote: post #117

Shocked by the negativity around this. I tested early versions of zod v4 and liked the new API, but was very concerned about what will be the migration path. I was even going to suggest to publish under a new package name. But the author's approach is ingenious. It allows for someone like me to start adopting v4 immediately without waiting for every dependency to update. Well done!

Yeah, it's a nice route. There's no way I could afford to do an all or nothing migration for something like validation.

Re: Zod 4

#162

Post by Shacklz »

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…

Many thanks for your work! Definitely looking forward to the upgrade - especially the performance-boosts with regards to tsc will be very welcome in our relatively large code-base, and the changes to discriminated unions will probably help us big time in a very specific scenario where so far they fell short.

That being said, I'm fully understanding of the reasons for the somewhat odd versioning given your special situation, but still, I'd wish there would be a 4.0.0-package for folks like us who simply don't need to worry or bother about zod-version-clashes in transitive dependencies bacause those don't exist (or at least I think so; npm ls zod only returns our own dependency of zod). If I understood correctly, we'll need to adapt the import to "zod/v4", which will be an incredibly noisy change and will probably cause quite a few headaches when IDEs auto-import from 'zod' and such, which we then need to catch with linting-rules.

But that's probably a small gripe for a what sounds overall like a very promising upgrade - many thanks for your work once again!

Re: Zod 4

#163

Post by kaoD »

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

Re: Zod 4

#164

Post by paulddraper »

gejose wrote: post #56
rafram wrote: post #39

> To simplify the migration process both for users and Zod's ecosystem of associated libraries, Zod 4 is being published alongside Zod 3 as part of the zod@3.25 release. [...] import Zod 4 from the "/v4" subpath npm is an absolute disaster of a dependency management system. Peer dependencies are so broken that they had to make v4 pretend it's v3.

> Peer dependencies are so broken that they had to make v4 pretend it's v3 I'm not sure this is the right conclusion here. I think zod v4 is being included within v3 so consumers can migrate over incrementally. I.e refactor all usages, one by one to `import ... from 'zod/v4'`, and once that's done, upgrade to v4 entirely.

But that was always a choice.

You can import aliases.

If you have a code that needs to use two versions of axios, or zod, or whatever...

  "zod4": "npm:zod@4.0.0"

Re: Zod 4

#165

Post by [deleted] »

cluckindan wrote: post #3

Between GraphQL and Zod, there really is no comparison. The latter feels clunky and superfluous by design when the former ecosystem can smoothly provide static TS typings without extra work or schema duplication.

[deleted]

Re: Zod 4

#166

Post by Spivak »

dmkolobov wrote: post #160
skydhash wrote: post #148

Earlier quoted context omitted.

I get the wish to have that, but IMO, it's a flawed approach. The frontend and the backend are generally different domains. Initially, their model may look alike, but they will probably differs during the lifetime of the project as they serve different needs. That's why the shape of the data stored in the DB differs from the one involved in business logic, which differs from the DTOs, which can differs from the objec…

The point is that somewhere, you need to chuck bytes over the network and someone needs to receive them. If the teams working on the two are different, or even if the expertise level is uneven, something like a typed serialization library is a great boon. At work, I maintain a Haskell-like programming language which spits out JSON representations of charts over OLAP queries. I’m the only one who knows the language ex…

> If the teams working on the two are different, or even if the expertise level is uneven, something like a typed serialization library is a great boon.

You don't even need that, I use typed serialization on both sides when talking to myself. How else do I guarantee the shape of what I send and receive? I want my codebase to scream at me if I ever mess it up.

Re: Zod 4

#167

Post by waynenilsen »

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 had so much difficulty with recursive types mixed with discriminated union (think xml in json for example) hopefully it'll be better now

Re: Zod 4

#168

Post by 9dev »

sensanaty wrote: post #82
koakuma-chan wrote: post #38

Earlier quoted context omitted.

> For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate. Or just use an LLM.

LLMs can't even not write React when you explicitly tell them not to write React in your Vue codebase. I still, with Gemini 2.5 Pro and Claude 3.7 both, get this annoying ass interaction almost daily, despite a universe of context there that should make it obvious I don't want a React component in my Vue codebase.

Do you mean TSX? Because Vue supports that. Might be worth asking it to create a SFC file and no TSX explicitly in your case!

Re: Zod 4

#169

Post by e1g »

Shacklz wrote: post #162
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…

Many thanks for your work! Definitely looking forward to the upgrade - especially the performance-boosts with regards to tsc will be very welcome in our relatively large code-base, and the changes to discriminated unions will probably help us big time in a very specific scenario where so far they fell short. That being said, I'm fully understanding of the reasons for the somewhat odd versioning given your special sit…

+1. We use Zod only for internal validation and would love a standalone release for v4 (or another package like zod4 or @zod/zod). I'm sure many greenfield projects would prefer that, too.

Re: Zod 4

#170

Post by Dylan16807 »

rafram wrote: post #84
90s_dev wrote: post #54

Earlier quoted context omitted.

Array.isArray isn't needed when you know your array isn't going to be deserialized e.g. via MessagePort. What other supposed bugs? And yes I'm aware this doesn't have a huge API surface. That's the whole point. If I already have a JSON object, I can reach into it and get either what I ask for or nothing. In many real world cases, this is enough.

let someArray = [1, 2, , 4]; console.log(as.numbers(someArray) === someArray); // => true for (let number of numbers) { // This should be safe because I know everything in the array is a number, right? console.log(number.toFixed(2)); // => TypeError: number is undefined } I mean, it's probably fine if you're only ever getting your data from JSON.parse(). But I would hesitate to use this in production.

> I mean, it's probably fine if you're only ever getting your data from JSON.parse().

So 90% of use cases?

Post reply on HN