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

91–100 of 260 posts

Re: Zod 4

#91

Post by Daishiman »

nicksergeant wrote: post #80
8s2ngy wrote: post #35

Congratulations to the Zod team on the new release. At the risk of sounding overtly negative, I can't help but shudder when I think about the number of breaking changes outlined in the migration guide. 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. Having maintained a few frontend projects that are 4-5 years old at wor…

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.

Re: Zod 4

#92

Post by dankobgd »

i would use it if there was just 1 normal zod lib not like how it is now: zod and zod mini and who knows what. I rather use arktype or valibot if i am in browser only.

Re: Zod 4

#93

Post by Scarblac »

johnfn wrote: post #59
stephen_hn wrote: post #42

Earlier quoted context omitted.

I think you would use discrimated unions. const MyResult = z.discriminatedUnion("status", [ z.object({ status: z.literal("success"), data: z.string() }), z.object({ status: z.literal("failed"), error: z.string() }), ]); You can define passthrough behavior if there are a bunch of special attributes for a moderator but you don't want to list/check them all. With different methods that have different schema- If they sha…

Hmm, this is pretty interesting, but I still have issues. While Zod seems to be able to transform my server-returned object into a discriminated union, it doesn't seem to be able to tell which of the unions it is. For instance, say that api/user/mod-panel (e.g.) returns only moderator user objects. My API endpoint already knows that it will have moderator-related fields, but Zod forgets that when I parse it.

Then you don't use the discriminated union for that endpoint, but the schema that only accepts moderator user objects.

That's not surprising, "this endpoint will only return moderator user objects" is a bit of knowledge that has to be represented in code somehow.

Re: Zod 4

#94

Post by sroussey »

Hopefully someone can compare Zod4 to TypeBox.

Last I looked, the nice thing about TypeBox was that is _was_ JsonSchema just typed which was nice for interoperability.

Re: Zod 4

#95

Post by Scarblac »

johnfn wrote: post #75
iainmerrick wrote: post #64

Earlier quoted context omitted.

In Typescript at least, if the discriminated union is set up correctly, you just need a single check of the type field. That lets TS narrow the type so it knows whether e.g. `.posts` is present or not.

I think I can do this, yes, but it becomes a very large amount of repetitive work. Let's say I have api/profile (which has `.posts`) and api/user-directory (which does not). I define User as a discriminated union - one has type `user-with-posts` and one has type `user-no-posts`. OK, good so far. But now say I have a photo gallery, which returns photos on user. Now I have to add that into my discriminated union type,…

Change the design of the API so that the posts and the photos and so on are not returned inside the user object but on the same level as it.

So {user: {...}, photos: [...]}, not {user: {..., photos: [...]}}.

Alternatively define separate schemas for each endpoint that extend the base User schema. But I'd prefer having the same structure everywhere as much as possible.

Re: Zod 4

#96

Post by sroussey »

derN3rd wrote: post #55
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.

We've been using zod 4 beta already with great improvements but due to our huge codebase not being able to handle the required moduleResolution settings, we cannot upgrade... They could at least also publish it as a major version without the legacy layer EDIT: I've just seen the reason described here: https://github.com/colinhacks/zod/issues/4371 TLDR: He doesn't want to trigger a "version bump avalanche" across the…

Would not be hard for you or anyone else to do that as well.

Re: Zod 4

#97

Post by winstonp »

nicksergeant wrote: post #80
8s2ngy wrote: post #35

Congratulations to the Zod team on the new release. At the risk of sounding overtly negative, I can't help but shudder when I think about the number of breaking changes outlined in the migration guide. 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. Having maintained a few frontend projects that are 4-5 years old at wor…

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 am just simply not touching tailwind v3 -> 4. v4 is for new projects only.

Re: Zod 4

#98

Post by koakuma-chan »

collingreen wrote: post #83
koakuma-chan wrote: post #65

Earlier quoted context omitted.

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.

"It will solve all your problems!" "It didn't solve my problems" "You're the problem!"

> "You're the problem!"

He said users sent reports with hallucinated syntax, he wasn't even the one who used LLMs.

Re: Zod 4

#99

Post by sroussey »

satvikpendem wrote: post #22

Zod 4 looks good but even with their latest improvements, ArkType is still an order of magnitude faster. Sometimes for the sake of backward and syntax compatibility, it is difficult to make something much faster than a fully greenfield newer library. We recently did an analysis of all these types of tools for our project and decided to go with ArkType for partially this reason, the other was TypeScript ergonomics fel…

Why ArkType over TypeBox?

Re: Zod 4

#100

Post by sroussey »

varbhat wrote: post #8

I am not an expert here but I had a thought that JSON-Schema might be a good choice because since it's schema based, i can implement the validators in Non-Typescript languages too. https://ajv.js.org is one such JSON Schema library. How does zod compare to this?

It is a good choice and in that case TypeBox is a decent way to generate it.

And you can use AVJ or its own schema validation system (which is much faster, but only sync where avj has asynchronous validation options in case you want to check against a database or something).

Post reply on HN