One schema checks incoming data and supplies its TypeScript type
A request arrives with a string where your code expects a number. Zod lets you describe that expectation once, check the actual value, and derive the TypeScript type from the same definition. The README's Player example pairs a string username with numeric experience points. Parsing validates the input and returns a deep clone. z.infer gives you the corresponding type without a separate interface to keep synchronized. I'd use this at an application's entry points, where data crosses into code that assumes it has already been checked. Zod's parsing and type inference guide explains the contract.
What happened when we ran it
Our run of Zod commit 0b216ef failed during installation in 2 seconds, with exit code 1. We cloned it on October 4, 2026, in a fresh Debian sandbox with 3 CPUs and 8 GB of RAM, using image lab-node:22. The container was unprivileged and had no secrets. The install log ended with Unsupported package manager specification (nub@0.8.3) repeated four times. That identifies the specification the tooling rejected. It doesn't explain why it was unsupported, establish a missing system package, or show a remedy. The supplied measurements contain no build or test result.
The checkout contained 738 files, about 103,364 source lines, and occupied 15.5 MB. Our scan identified a Node ecosystem with pnpm, monorepo workspaces, and 8 CI workflow files. It found no Dockerfile and no tests directory. Those directory findings don't establish whether checks exist elsewhere in the monorepo, and workflow files don't establish passing checks. The immediate decision for a contributor is concrete: allow time to resolve the package-manager rejection before depending on this checkout. These figures describe the source repository. They don't measure the published library's browser payload, installed dependency footprint, or parsing speed.
Async checks require the async parsing methods
Zod supports Node.js and modern browsers; our sandbox used Node 22. The README's quick start installs the published package with npm install zod, a different path from preparing the source checkout. Ordinary validation runs inside your application without a Zod account, API key, or hosted service. TypeScript users need strict mode enabled, and official support starts at TypeScript 5.5. An asynchronous refinement, such as checking availability against a database, requires parseAsync or safeParseAsync. That database and its credentials belong to your application. Zod doesn't provide them or turn an asynchronous check into a synchronous operation.
JSON Schema export cannot preserve every JavaScript rule
Zod's JSON Schema conversion guide explicitly excludes constructs such as dates, maps, and standalone transforms because they have no direct equivalent. Conversion throws by default when it encounters an unrepresentable construct. Selecting unrepresentable: "any" can replace it with an empty schema, which accepts anything. That's a meaningful loss of a rule you may rely on locally. Conversion also describes output types by default, so callers documenting incoming data need to consider input mode. For a string transformed into another value, accepting the input and describing the output are different jobs. Keep exported contracts under review instead of assuming every rule in a Zod schema survives conversion.
Compiled validation can repeat callbacks on invalid input
The 2-second installation failure leaves Zod's compiled parser unmeasured in our sandbox. The README now documents z.compile, which adds a compiled path for valid inputs and uses the ordinary parser for errors. Its compilation restrictions deserve attention before adoption: code generation uses new Function, and global compilation stands down with jitless enabled. Async refinements and transforms cannot be compiled. On invalid input, refinements and transforms may run twice as parsing falls back. A callback that sends a message or changes stored state could therefore repeat an action. Keep validation callbacks free of those side effects, and compile the final schema because methods that derive another schema return an uncompiled one.
October maintenance includes an unresolved union error report
The last push was October 12, 2026, and release v4.6.7 was published that day. GitHub's API returned 44,101 stars and 93 open issues and PRs. Recent issue and pull-request updates support a judgment of active maintenance, though the latest release notes only list a version commit. Issue 6659 reports that v4.6.6 changed an oversized array's error inside a union from too_big to invalid_union. For a form that maps error codes to messages, that can replace a useful size warning with a generic error. This is a user report, separate from our install finding. Proposed fix PR 6662 remained open and unmerged when checked.
Choose alternatives by contract format and import style
Our 15.5 MB checkout says nothing about how much validation code your users download. If browser payload matters, compare Valibot's modular functions with Zod Mini's functional API using your actual schemas and bundler. We have no payload measurement that settles that choice. ArkType is another option when you prefer validation declarations closer to TypeScript syntax. I'd choose Zod for an application whose developers want readable schema methods and inferred types, while keeping error handling explicit. Choose Ajv's JSON Schema validator when a shared JSON Schema document is the contract other systems must consume. That avoids making a JavaScript schema's export limitations everybody else's problem. Before a Zod upgrade reaches users, check the invalid inputs your interface translates into messages, especially unions like the one in issue 6659.