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

141–150 of 260 posts

Re: Zod 4

#141

Post by johnfn »

mmcnl wrote: post #134
johnfn wrote: post #20

I'm curious if anyone here can answer a question I've wondered about for a long time. I've heard Zod might be in the right ballpark, but from reading the documentation, I'm not sure how I would go about it. Say I have a type returned by the server that might have more sophisticated types than the server API can represent. For instance, api/:postid/author returns a User, but it could either be a normal User or an anon…

Your server should export the types. Don't write types by hand in your client, that makes no sense. The server knows what data it is sending and should provide that information as metadata to the client. Practically this can mean that a Python backend uses Pydantic schemas which can be used to automatically generate an OpenAPI specification that your client can use to generate types.

This answer is how I wish the world would work, but I am stuck with a server with a poor type system that can't refine the types nearly as accurately as TS can. :(

Re: Zod 4

#142

Post by dangoodmanUT »

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…

ArkType is a nightmare to use, zod is nice to use

Re: Zod 4

#143

Post by vlovich123 »

yhprum wrote: post #103
satvikpendem wrote: post #69

Earlier quoted context omitted.

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

Yeah, I can't see zod really adding that much overhead in the critical latency path for all but extremely large responses. Sometimes people pick "the fastest" library without considering whether the performance is relevant for a given code path.

Re: Zod 4

#144

Post by paulddraper »

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…

Am I to understand the earliest version of Zod 4 is 3.25.0?

Does this not sound insane?

---

I've been using the alpha versions of Zod for months, I just want to edit package.json and upgrade. But now I need to shotgun across git history instead.

Colin, I appreciate your project immensely. As a point of feedback, you made this ^ much harder than you had to. (Perhaps publish a 4.x along with the 3.x stuff?)

Re: Zod 4

#145

Post by 90s_dev »

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.

The point is that it's layered.

1. Validate your Buffer/UInt8Array for valid size/encoding/etc first

2. Parse it to an object via JSON.parse or whatever your use-case needs

3. Reach into it with this function to get data if it matches the type you need

This code only deals with #3 and makes a few assumptions about #2 (e.g. no undefined, typical JSON-like object, etc).

Re: Zod 4

#147

Post by Sammi »

diggan wrote: post #116
herrkanin wrote: post #101

Earlier quoted context omitted.

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?

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?

Re: Zod 4

#148

Post by skydhash »

Sammi wrote: post #140
skydhash wrote: post #118

Earlier quoted context omitted.

If it's part of your core domain, I'd say that one of the reasons you want the feature set and the API to be as stable as possible. And your core domain should probably be isolated from the things that depends on it in such way that only business logic ripples out. One of the strange things from the NPM/JS culture is the focus to write everything in one language leading to everyone forgetting about modularization and…

You use Zod to define all the schemas and types used in "your core domain". It is the base layer tool of your business logic and models, and for defining your interfaces. And yes it makes it possible to share all of this between the frontend and backend, which is a tremendous improvement in both correctness and in development productivity. You don't get anything remotely like this in any other backend frontend combo.

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 objects involved in the presentation.

In simple applications, you can get away with defining a single schema for all, but it helps with keeping in mind that you may have to design a better data shape for some logic.

Re: Zod 4

#149

Post by __natty__ »

Great job! I love support of json conversion you built-in. However, I find top level string bad choice as it was more verbose before, to have them under string() namespace.

Re: Zod 4

#150

Post by lhnz »

dangoodmanUT wrote: post #142
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…

ArkType is a nightmare to use, zod is nice to use

Out of interest, why is it a nightmare to use?

I've always been worried about how overly clever the approach is, does it have problems?

Post reply on HN