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

221–230 of 260 posts

Re: Zod 4

#221

Post by andrewingram »

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…

Is there any interop between v3 and v4 schemas themselves? We have an enormous graph of hundreds (if not thousands) of Zod schemas, many inheriting or extending others. It's difficult to envisage us being able to do an incremental upgrade unless both versions can interact neatly.

But I am looking forward to seeing if this fixes our issue where in the worst case a 500 line schema file turns into 800,000 lines of generated types.

Re: Zod 4

#222

Post by andrewingram »

_1tem wrote: post #212

As a full stack dev that runs their own SaaS with thousands of users in production, sometimes I get a very pleasant reminder of how many problems I am blissfully unaware of just because I decided not to build an SPA or use JS frontend frameworks. It never occurred to me that I need such a thing as Zod/ArkType - first time hearing of it, and I have no use for it. It boggles my mind how much effort and complexity and t…

We have an enormous number of backend-only Zod schemas that are used as part of our data pipelines; so it doesn't seem like something that only exists to solve SPA problems.

Re: Zod 4

#223

Post by diggan »

Sammi wrote: post #210
skydhash wrote: post #158

Earlier quoted context omitted.

If they need the new one, they will switch to it. And you have the right to drop support for the old one after a while (hopefully giving everyone the time to migrate).

> If they need the new one, they will switch to it. I already gave my argument on why this won't happen. People stick to what they know and trust. They don't change because there is some other thing that is supposedly better. It has to be 10x better before people will migrate off one thing to another. If you want to do incremental improvements to a thing, then you'll have to do incremental improvements to that thing.

> They don't change because there is some other thing that is supposedly better. It has to be 10x better before people will migrate off one thing to another.

That's the point, and it makes sense from their perspective, I'd probably do the same as well.

Creating a new library instead of changing the existing one lets people chose between those two approaches. Want the latest and greatest but with API breakage? Use this library. Wanna continue using the current API? Use this library.

Instead, we kind of force the first approach on people, which I personally aren't too much of a fan of.

Re: Zod 4

#224

Post by _1tem »

SebastianKra wrote: post #215
_1tem wrote: post #212

As a full stack dev that runs their own SaaS with thousands of users in production, sometimes I get a very pleasant reminder of how many problems I am blissfully unaware of just because I decided not to build an SPA or use JS frontend frameworks. It never occurred to me that I need such a thing as Zod/ArkType - first time hearing of it, and I have no use for it. It boggles my mind how much effort and complexity and t…

Well how do you do server-side validation? Because now I have the impression that you're just defensively writing a bunch of if-statements. Or worse, you rely on html client-side form validation only.

Any good backend framework (Laravel, Django, Livewire, Rails) does server side validation out of the box without me as a developer needing to manually pass around JSON objects and continually checking their shape. The boundary between user input and backend code is well defined and border checks are easy.

Re: Zod 4

#225

Post by _1tem »

andrewingram wrote: post #222
_1tem wrote: post #212

As a full stack dev that runs their own SaaS with thousands of users in production, sometimes I get a very pleasant reminder of how many problems I am blissfully unaware of just because I decided not to build an SPA or use JS frontend frameworks. It never occurred to me that I need such a thing as Zod/ArkType - first time hearing of it, and I have no use for it. It boggles my mind how much effort and complexity and t…

We have an enormous number of backend-only Zod schemas that are used as part of our data pipelines; so it doesn't seem like something that only exists to solve SPA problems.

If it’s backend only why do JSON shapes need to be continually checked? Can’t you serialize higher level classes or use the database?

Re: Zod 4

#226

Post by _1tem »

zachrip wrote: post #217
_1tem wrote: post #212

As a full stack dev that runs their own SaaS with thousands of users in production, sometimes I get a very pleasant reminder of how many problems I am blissfully unaware of just because I decided not to build an SPA or use JS frontend frameworks. It never occurred to me that I need such a thing as Zod/ArkType - first time hearing of it, and I have no use for it. It boggles my mind how much effort and complexity and t…

Zod has nothing to do with SPAs and isn't just a frontend tool. Do you not validate inputs in your code?

Laravel/Livewire handles it. I have no idea why something like Zod should be the concern for a high level application dev. For a framework dev, sure

Re: Zod 4

#227

Post by _1tem »

giorgioz wrote: post #214
_1tem wrote: post #212

As a full stack dev that runs their own SaaS with thousands of users in production, sometimes I get a very pleasant reminder of how many problems I am blissfully unaware of just because I decided not to build an SPA or use JS frontend frameworks. It never occurred to me that I need such a thing as Zod/ArkType - first time hearing of it, and I have no use for it. It boggles my mind how much effort and complexity and t…

What's your SaaS? I would like to check out your use case that allowed you to build a great product without SPA.

Basecamp and Hey are $100m+ software companies that use Ruby on Rails without an SPA.

Re: Zod 4

#228

Post by dhruvrajvanshi »

_1tem wrote: post #224
SebastianKra wrote: post #215

Earlier quoted context omitted.

Well how do you do server-side validation? Because now I have the impression that you're just defensively writing a bunch of if-statements. Or worse, you rely on html client-side form validation only.

Any good backend framework (Laravel, Django, Livewire, Rails) does server side validation out of the box without me as a developer needing to manually pass around JSON objects and continually checking their shape. The boundary between user input and backend code is well defined and border checks are easy.

> manually pass around JSON objects and continually checking their shape

Well Zod is a library that's typically used on the boundary.

I don't know why you're assuming stuff about a library that you've never used. No one would continually check their shape once it's validated at the api boundary.

Re: Zod 4

#229

Post by presentation »

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.

Looks like there are libraries for generating zod schemas from OpenAPI definitions and others.

https://zod.dev/ecosystem?id=x-to-zod

Re: Zod 4

#230

Post by CGamesPlay »

LinusU wrote: post #206
CGamesPlay wrote: post #179

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…

Library authors should only import from `core`, which is used by both v4 and v4-mini. ref: https://zod.dev/library-authors?id=how-to-support-zod-and-zo...

Glad to see that this was also considered. I’m curious why they went with a third API, though.
Post reply on HN