zod

The commit was still not only in git history, but also on the release page on github for 4.6.6: https://github.com/colinhacks/zod/releases/tag/v4.6.6 So I think it's not a great leap to think this commit actually made it to 4.6.6 on npm. Good that it didn't though!

The compromised code is still tagged on Github as of 2026-10-12T10:37:51: https://github.com/colinhacks/zod/releases/tag/v4.6.6. See commit d821685.

I haven’t downloaded the tarball to verify, but it looks like it was reverted prior to the GitHub release: https://github.com/colinhacks/zod/commit/10dda3a3a4bc76ed0bf...

The most recent version 4.6.6 has a very interesting commit (d821685) "Fix bugs and improve performance", that contain the following changes https://github.com/colinhacks/zod/commit/d821685ea6732436fcd... I didn't study what packages/mini/meta.test.mjs is doing in particular but it's not looking great

I built a TypeScript validation library after getting frustrated with FormData in Remix/Next.js Server Actions. The problem: Zod (the most popular validation library) doesn't have FormData support. It's their #1 requested feature with 60+ upvotes on GitHub [1], but they haven't implemented it. So every Server Action looks like this: const name = formData.get('name') as string; const age = parseInt(formData.get('age') as string); // ... manual validation I wanted: const result = validateFormData(formData, schema); // Automatic type conversion, validation done While building this, I also added: - Partial validation (return valid data even with errors - useful for auto-save) - JSON Schema export (built-in, no external package needed) - File validation (size, MIME types) - XOR support (exactly one of these fields) Zero d

Zod doesn't give you the ability to serialize or de-serialize schemas, unless you convert to JSON schema, which is verbose. See: https://github.com/colinhacks/zod/discussions/2030

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

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

Yep, at some indeterminate point when I gauge that there's sufficient support for Zod 4 in the ecosystem, I'll publish `zod@4.0.0` to npm. This is detailed in the writeup[0] [0] https://github.com/colinhacks/zod/issues/4371

Sorry if it's mentioned in the article but I'm on mobile. Is fixing .optional() in TS[0] part of the 9/10 top-issues fixed? This has been my biggest pain point with Zod... but still Zod is so good I still choose to just deal with it :) Thanks for an amazing part of the ecosystem. [0] https://github.com/colinhacks/zod/issues/635

This is not done for Zod's benefit. It's done for the benefit of libraries that depend on Zod, and the users of those libraries. If a library wants to add "incremental" support for Zod4 (that is, without dropping support for Zod 3 and publishing a new major), they need access to types (and possibly runtime code) from both libraries to do so in a sound way. I detail a number of other approaches for achieving this here[0] and why they ultimately fall short. Ultimately npm wasn't designed for this particular set of circumstances. [0] https://github.com/colinhacks/zod/issues/4371

First thank you for the hard work, many of my local hacks will go away with the new features! As a convenience and mostly avoid typos in form names I use my own version of https://github.com/raflymln/zod-key-parser. I've been surprised something like this hasn't been implemented directly in the library. Curious if you think this is out of scope for Zod or just something you haven't gotten around to implement? (Here are discussions around it: https://github.com/colinhacks/zod/discussions/2134)

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 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 anal