201–210 of 260 posts
Seeing an announcement for a new version of some typescript library I've never heard of shoot to the top of the front page makes me feel extremely out of touch with mainstream dev.
What do you use for validation in TS? Anyone who deals with data should be validating/parsing it.
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.
The thing I like about Zod is the "refinements" and "transforms" and the new "overwrite" in Zod 4 was just what I wanted.
TypeBox does have a transform (https://github.com/sinclairzx81/typebox?tab=readme-ov-file#t...) but you can't transform and then apply more validations and then maybe another transform, etc. For example, I like to trim strings before checking length.
But how is the below possible - doesn't it need to include most of the TypeScript compiler? Does it compile the type definitions to some kind of validation structure (like how a compiled regex works) and then use just that? - Zero external dependencies - Works in Node.js and all modern browsers - Tiny: 2kb core bundle (gzipped)
The TypeScript compiler is only needed during development, the compiled JavaScript code contains no TypeScript-specific logic. Zod’s validation is entirely JavaScript-based, relying on simple checks (e.g., typeof, regexes, comparisons). Also, the 2kb bundle just for the zod/v4-mini package, the full zod/v4 package is quite large.
Earlier quoted context omitted.
Can you elaborate?
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.
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…
ref: https://zod.dev/library-authors?id=how-to-support-zod-and-zo...
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…
Breaking changed in fundamental but auxiliary libraries are so painful in the world of frontend development that it's not even funny anymore.
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…
Eslint 8 → 9 was not just incredibly painful with a shock wave that still propagates through the industry, but it was also totally useless
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…
This is extremely sensible. And it means you can provide security updates for older versions, just all in the same codebase's releases.
Earlier quoted context omitted.
People wouldn't change to the new one, because names are extremely sticky, so what's the point?
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).
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.