Live data from Hacker News

Zod 4

zod.dev

241–250 of 260 posts

Re: Zod 4

#241
post #112

Earlier quoted context omitted.

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.

Yeah, importing two versions could allow you to pass v3 objects to v4 methods and vice versa, and that seems like an extremely bad idea (if it would even type-check / run).

It won't typecheck, which is good in this case, because as you say that's a very bad idea :)

Re: Zod 4

#242
post #107

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?

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.

As you allude to: your aliased "zod-next" dependency wouldn't be able to satisfy the requirements of any packages with a peer dep on Zod. But this approach has a more fundamental flaw. My goal is to let ecosystem libraries support Zod 3 and Zod 4 simultaneously. There's no reliable way to do that if they aren't in the same package.[0]

[0] https://github.com/colinhacks/zod/issues/4371

Re: Zod 4

#243
post #226

Earlier quoted context omitted.

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

In that case, your objection seems to be to light weight or minimal frameworks rather than SPAs on this point. There are plenty of minimal backend frameworks for Node (and Python, and others) that can be and are used to build traditional "load a page for every interaction" applications, and Zod or something like it would be useful for those since minimal frameworks often don't include validation. Zod isn't exclusively for SPAs or even web applications. It's schema validation, which is useful in many domains.

Re: Zod 4

#244
The versioning approach here is a really interesting compromise — especially in the npm ecosystem where breaking changes ripple out so painfully through transitive dependencies. From a developer ergonomics standpoint though, the shift to zod/v4 imports will definitely create some friction. For teams with IDEs auto-importing from 'zod' and linters enforcing import styles, it might introduce subtle DX issues until workflows are adjusted.

That said, the strategy does seem to prioritize ecosystem stability over short-term convenience, which is fair. Would love to see better tooling (maybe even IDE plugins or codemods) to help projects transition cleanly. Really appreciate the thoughtful design behind all of this.

Re: Zod 4

#246

Earlier quoted context omitted.

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.

That's going in the wrong direction IMO. TypeScript checks types only, not business logic. Zod does both.

Zod's way to check business logic is extremely underpowered and, again, it's not reusable!

Re: Zod 4

#247

Earlier quoted context omitted.

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?)

I understand this as a knee-jerk reaction. I didn't do this lightly. > Perhaps publish a 4.x along with the 3.x stuff You have some misconceptions about how npm works. Unfortunately it's less reasonable than you think. There's a single `latest` tag, and there's only one "latest" version at a time. It's expected that successive versions here will follow semver. Once I publish zod@4 I can no longer publish additional z…

You can absolutely publish 3.x.x after 4.x.x, they just won’t be “latest” (of course).

Speaking bluntly, this isn’t how libraries in the npm upgrade, and pitching this does not inspire confidence.

Re: Zod 4

#250
post #226

Earlier quoted context omitted.

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

Zod is basically the standalone version of Laravel's validation (https://laravel.com/docs/12.x/validation#quick-writing-the-v...) so I'm not sure what exactly you're objecting to.

Unless you're saying

a) You don't validate user inputs b) You prefer validation to be bundled with the framework rather than having a choice

Post reply on HN