231–240 of 260 posts
The website fails to load with a javascript error in Safari. `SyntaxError: Invalid regular expression: invalid group specifier name`
Lookbehind in JS regular expressions - https://caniuse.com/js-regexp-lookbehind
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
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…
In the end you'll have a schema somewhere. Maybe defined in the database system, maybe defined in the models of an object-relational mapper. Since defining the schemas in database system or using object-relational mappers can cause very difficult problems in large projects we do not use it and use Zod and Protobuf instead. While I think you could even replace Protobuf completely with Zod or something similar.
There is the British Post Office scandal [1] around an IT system called Horizon (the legacy system in this case). After reading about the details I'm pretty sure something like Zod (I mean any schema validation) would have contributed to prevent this scandal. They even mentioned the lack of using a schema in the technical appendices in the court documents of the group legal action [2].
[1] https://en.wikipedia.org/wiki/British_Post_Office_scandal
[2] https://en.wikipedia.org/wiki/Bates_%26_Others_v_Post_Office...
Earlier quoted context omitted.
> 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 thi…
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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
Well zod is for typescript, not laravel/livewire
Lately, I used code agents a lot, and having typescripts types infered from Zod schemas allows me to catch errors when the large-language model generated slightly wrong code.
Earlier quoted context omitted.
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.
But once you don't use ORMs or have a non-monolithic architecture, you need something to validate your schema.
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 gener…
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 gener…
Report back about that .d.ts issue. It should be far better. That kind of type explosion usually happens when TypeScript needs to infer function/method return types. Zod 4 uses isolatedDeclarations so this kind of thing shouldn't happen.
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?)
> 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 zod@3.x.x versions. The workaround here is to publish v3 versions to a separate dist tag (zod@three) but anyone consuming that dist-tag (e.g. "zod": "three" in their package.json) loses the ability to specify a semver range.
I recommend reading the writeup[0]. I don't think you're appreciating the magnitude of the disruption a simple major version bump would have caused, or the reasons why this approach is necessary to unlock continuity for Zod's ecosystem libraries. They're quite subtle.