-
ajv
The fastest JSON schema Validator. Supports JSON Schema draft-04/06/07/2019-09/2020-12 and JSON Type Definition (RFC8927)
I am not an expert here but I had a thought that JSON-Schema might be a good choice because since it's schema based, i can implement the validators in Non-Typescript languages too.
https://ajv.js.org is one such JSON Schema library. How does zod compare to this?
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Obligatory shameless plug whenever Zod is posted: if you want similar, but much more minimal schema validation at runtime, with a JSON representation, try Spartan Schema: https://github.com/ar-nelson/spartan-schema
-
OpenAPI TypeScript is the closest thing I’ve found to perfection when your API is written in a different language than your client.
https://openapi-ts.dev/
-
-
Author here. I wrote a fairly detailed writeup here[0] for those who are interested in the reasons for this approach.
Ultimately you're right that npm doesn't work well to manage the situation Zod finds itself in. But Zod is subject to a bunch of constraints that virtually no other libraries are subject to. There are dozens or hundreds of libraries that directly import interfaces/classes from "zod" and use them in their own public-facing API.
Since these libraries are directly coupled to Zod, they would need to publish a new major version whenever Zod does. That's ultimately reasonable in isolation, but in Zod's case it would trigger a "version avalanche" would just be painful for everyone involved. Selfishly, I suspect it would result in a huge swath of the ecosystem pinning on v3 forever.
The approach I ended up using is analogous to what Golang does. In essence a given package never publishes new breaking versions: they just add a new subpath when a new breaking release is made. In the TypeScript ecosystem, this means libraries can configure a single peer dependency on zod@^3.25.0 and support both versions simultaneously by importing what they need from "zod/v3" and "zod/v4". It provides a nice opt-in incremental upgrade path for end-users of Zod too.
[0] https://github.com/colinhacks/zod/issues/4371
-
bundlejs
An online tool to quickly bundle & minify your projects, while viewing the compressed bundle size, all running locally on your browser. A quick and easy way to bundle, minify, and compress (gzip and brotli) your ts, js, jsx and npm projects all online, with the bundle file size.
These numbers don't reflect anything useful. This is the total size of the code in the package, most of which will be tree-shaken. In Zod's case, the package now contains three independent sub-libraries. I recommend plugging a script into bundlejs.com[0] to see bundle size numbers for a particular script
[0] https://bundlejs.com
-
I was using TypeBox but switched to Zod. I like TypeBox but I found I don't actually need my schema to be a JSON Schema and the one time I did want a JSON Schema it was hard to get actual JSON back out of TypeBox.
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.
-
> I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide.
I have never used Cursor, but I see more and more people who used LLMs specifically via Cursor complain. It makes me think there's an issue specifically with Cursor, e.g., they try to save on tokens and end up not including enough context in the prompt.
> I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide.
I am working on a Next.js 15 / React 19 app, and at least 95% of code is written by Gemini 2.5 Pro Preview, and barely ever need to "fight" it really. But it's not a Cursor workflow of course. I keep a directory with LLM-readable documentation[0], use a repository serialization tool to serialize my repository into a prompt (this includes both the source code and the LLM-readable documentation), and sent it to Gemini 2.5 Pro Preview. It ends up being over 100K tokens per query but works really well for me.
[0]: https://llmstxt.org/