I swear there was another package out there that recently introduced Zod support (I checked Collections2 and Autoform and it doesn’t seem to be them, maybe I’m imagining things) It was Collections2…
The breaking changes don’t look that severe, but I’m pretty sure a lot of refactoring was done.
Essentially performance, both in terms of runtime type checking and TypeScript type inference, should be improved. Some design ideas were adapted from Valibot to create a tree-shakeable API for frontends (probably would require jorgenvatle:vite at the moment to tree-shake properly?). And from the new docs it seems Standard Schema gets a few mentions which might be of interest in the Meteor community since we have usage split between meteor/check, simpl-schema, jam:easy-schema and zod (amongst others).
One thing I’m personally interested in is the new metadata registry + the inbuilt z.toJSONSchema() method . As a community, we could use that as in jam:easy-schema to add JSON Schema validation to our MongoDB collections, and personally, I’m interested in somehow bolting validation and OpenAPI docs onto the meteor/webapp package.
I get that, it can be a bit overwhelming with all the updates. If you need any help or want to brainstorm how to implement the changes, feel free to reach out. I’m curious to see how the performance improvements play out in real projects!
The good news is that they’re taking some sort of Go-style module versioning approach where you have a sub-package per version, which will make incremental migration easier from a peer-dependency POV.
(It uses module subpath stuff that typically breaks build systems so I personally need to test if it works alright with Meteor + Vite.)
EDIT: Also quoting the Github issue (bolding mine):
Zod 4 will not initially be published as zod@4.0.0 on npm. Instead it will be exported at a subpath ("zod/v4") alongside zod@3.25.0
Despite this, Zod 4 is considered stable and production-ready
Zod 3 will continue to be exported from the package root ("zod") as well as a new subpath "zod/v3". It will continue to receive bug fixes & stability improvements.
But you might end up with a mix of v3 and v4 schemas I guess if a package doesn’t support v4 APIs, which is more likely to happen with things like autoform-style libraries which need to drill down into the schema shape, rather than things that make simple call likes mySchema.parse(...).
For autoform-style libraries, if it supports JSON Schema as an input, then you can simply do mySchema.toJSONSchema(). Otherwise that library will need to support ._zod. def instead of ._def etc.
I did a quick test but the package does not seem compatible with meteor’s current bundler - it requires changing tsconfig.json’s moduleResolution to node16 or bundler and even after that, zod/v4 could not be found by Meteor’s bundler.
Hmm sometimes this is resolved by vite but if the package.json is configured incorrectly occasionally it doesn’t work at all in production (something that came up with Hono for me).
Generally those problems are related to ESM export aliases.
. As a community, we could use that as in 