Live data from Hacker News

Zod 4

zod.dev

101–110 of 260 posts

Re: Zod 4

#101
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.

I might be blindsided by using npm exclusively for years by this point, but what would be a better way to support iteratively migrating from v3 to v4 without having to do it all in one large batch?

Re: Zod 4

#102

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.

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.

Re: Zod 4

#103
post #66

Earlier quoted context omitted.

I was looking at all their speed metrics, and can you explain to me where the speed makes a difference? We only use zod to validate forms, so I keep thinking "how does this matter?" Are people maybe using it to validate high throughput API input messages or something like that, where performance may matter more?

Yes, we use it to validate the API responses from the backend (as well as type validation on the backend itself from any frontend POST requests), and especially on the client side, speed and bundle size is very important.

Does arktype not come with a larger bundle size than zod? That was the reason I was shying away from it at the moment, especially with the bundle size reductions with zod 4 as well

[1] https://www.reddit.com/r/typescript/comments/1i3ogwi/announc...

Re: Zod 4

#104
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.

apart from the other things people raised, as leerob also points out it hints to an llm that the api may be different https://x.com/leerob/status/1924504939818008791

Re: Zod 4

#105
post #55
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…

Yeah this seems like very poor reasoning tbh.

Re: Zod 4

#107
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.

I might be blindsided by using npm exclusively for years by this point, but what would be a better way to support iteratively migrating from v3 to v4 without having to do it all in one large batch?

Using npm's built in support for package aliases to simultaneously install zod@3 as zod and zod@4 as zod-next?

Edit: reading the rationale, it's about peer dependencies rather than direct dependencies. I am still a little confused.

Re: Zod 4

#108
post #63

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.

Ah yes two totally different technologies - let's compare them like they're designed to solve the exact same problem

GraphQL is a different animal, but I was only comparing the features Zod implements to those found in the GraphQL ecosystem.

Re: Zod 4

#109
post #4

We're currently evaluating both Zod and ArkType as a replacement for earlier JSON schema validations. The thing I can't get over with Zod is the syntax is _so_ different from defining TS types. Are there reasons to go with Zod over ArkType?

We also chose ArkType after evaluating Zod, Valibot, and Effect Schema, among others. It seemed to have the best developer experience while also being much faster. It also supports the Standard Schema project which I believe Effect Schema does not fully support.

Could you elaborate on how exactly do you use these? I was assuming its for some kind of contract testing, but there are mentions of bundle size, is it used on fetching data to fail early if the format is wrong, something like that?

Re: Zod 4

#110
post #56
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.

How do you even migrate incrementally? why keep both old and new code together like a Frankeinstein project? Especially on a codebase you own. It's a library, not a platform.
Post reply on HN