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

171–180 of 260 posts

Re: Zod 4

#171

Post by jmull »

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…

A perfectly valid evolution strategy is to add new APIs while keeping the old (which you may or may not choose to deprecate). That is, add the new APIs to 3.x (but probably call them something other than v4.

Now, that's effectively what 3.25 is. But there are some problematic extras... the semantics of the semantic versioning is muddled. That means confusion, which means some people will spin their wheels after not initially grokking the situation correctly. Also, there seems to be an implication there could be a strong deprecation of v3 APIs coming. That is, you have to wonder how long the window for incremental migration will remain open.

To be frank, I wouldn't touch zod on any project I hoped will be around for a while. Predicting the future is an uncertain business, but we can look at the past. In a few years, I think it's reasonable to guess zod v4 will be getting the same treatment zod v3 is getting now.

Not that I think you ought to do anything different. I probably wouldn't want to maintain some old API I came up with years ago indefinitely either (not without a decent support contract, that is).

Re: Zod 4

#172

Post by pier25 »

Sammi wrote: post #147
diggan wrote: post #116

Earlier quoted context omitted.

One possible solution: Publish a new package with a new name. I've personally been thinking of doing that for some libraries, where I'd commit to never change the public API, and if I figure out a nicer way of doing something, I'd create a new library for it instead, and people who wanna use/maintain the old API can continue to do so.

People wouldn't change to the new one, because names are extremely sticky, so what's the point?

The point is API stability. Not enough people in the JS world care about this.

Re: Zod 4

#173

Post by pier25 »

Daishiman wrote: post #91
nicksergeant wrote: post #80

Earlier quoted context omitted.

I am 100% in agreement here. I operate a couple large Next.js apps and in the last year we've had to deal with Next.js 14 -> 15 which introduced a ton of breaking cache changes, Next.js pages -> app router, React 18 -> 19, Eslint 8 -> 9, and Tailwind 3 -> 4. It's honestly been a nightmare, and I wish I had just built in Django instead. The Tailwind 3 -> 4 migration was probably among the most painful, which I was not…

I will continue to beat the drum that using easy-to-migrate frameworks like Django that don't go around introducing major breaking changes is one of the bigger web development superpowers.

Couldn't agree more. I'm considering getting into Phoenix for this very reason.

Re: Zod 4

#174

Post by pier25 »

skydhash wrote: post #114
hombre_fatal wrote: post #102

Earlier quoted context omitted.

Django doesn't run in the browser though. All of the tech they listed can run in the browser which gives you other superpowers at the expense of having moving targets, but that's what they opted into when they decided to run code on user machines instead of in a single server environment.

The main browser API is pretty stable, all things considered. It's just that people can't seem to stay put on a given design, instead trying everything under the sun. When you have something like SDL which is at it's third version at 27 years old, I'm very doubtful about the culture of NPM/JS world. A closer example is jQuery which is also in its third version at 18 years old.

jQuery should get more praise for this.

Re: Zod 4

#175

Post by skybrian »

esafak wrote: post #13
koolba wrote: post #9

Earlier quoted context omitted.

But that’s the whole point of something like this. You do it once and dynamically generate everything else downstream. So change it once in the zod schema and it propagates with type checking through your entire app. The zod schema becomes the source of truth.

Does it? I don't use Zod on my JVM backend. How would I? In addition to using OpenAPI, I generate TS interfaces from my data classes in a Gradle task.

One way might be to convert the Zod schema to a JSON schema and then to Java? I found a library to do that. [1] But I don’t know how lossy that would be. A purpose-built converter might do better.

[1] https://jsontypedef.com/docs/java-codegen/

Re: Zod 4

#176

Post by msukkarieh »

We've been using zod for our open source tool and are loving it! Will definitely try to migrate over to v4 soon, thanks for the project!

Re: Zod 4

#177

Post by elanora96 »

koakuma-chan wrote: post #65
cscheid wrote: post #52

Earlier quoted context omitted.

This is the kind of task that LLMs are precisely terrible at; there isn't an abundance of Zod 4 examples, and the LLM will sure as shit will give you _something_ you are now by definition ill-equipped to assess. I'm confident about this assessment because I maintain a large-ish piece of software and perenially have to decipher user reports of hallucinated LLM syntax for new features.

Are you sure that's not a skill issue? Zod v4 has .mdx documentation which can be given to the LLM as context, including a migration guide. A reasoning LLM should be able to manage.

I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide. It also kept telling me to install irrelevant dependencies saying my code would not work without them. My experience was more or less shared with several other senior devs using their companies AI subscriptions. Are we all using the tools wrong? Or is there just an expected amount of having to fight with the machine to get a usable result?

Re: Zod 4

#178

Post by nikolay »

rlt wrote: post #90
nikolay wrote: post #85

Zod and the way to define schemas with it has been one of the reasons I didn't want to touch TypeScript as it's becoming more prevalent!

Can you elaborate?

It defines yet another way to declare schemas in a way that's not reusable. ArkType mostly uses TypeScript's, so, it feels more natural.

Re: Zod 4

#179

Post by CGamesPlay »

One decision that seems dubious to me is the zod/v4-mini import. I suspect that this will actually increase bundle sizes across the ecosystem. The docs specifically say "zod/v4 is still recommended for the majority of use cases", so application developers will use it. Library authors will think to themselves, "but I want to enable my library to be used by those with uncommonly strict bundle size requirements", and so will use that. The net result is that both zod/v4 and zod/v4-mini will be included in the application bundle.

I guess this could be mostly avoided if zod/v4 actually a wrapper around zod/v4-mini. Is that the case?

Post reply on HN