Follow zod guidance on supporting v4 - for users incrementally migrating from v3

[Sam152]

This PR does not add support for zod v3, but instead makes the integration of this package gentler on folks with large v3 codebases, trying to incrementally adopt v4.

In the zod docs for package authors it describes the following:

To support Zod 4, update the minimum version for your "zod" peer dependency to ^3.25.0 || ^4.0.0.
...
Do not import from these subpaths:
"zod" — ❌ In 3.x releases, this exports Zod 3. In 4.x releases, this will export Zod 4. Use the permalinks instead.

Importing from zod/v4 acts as a permalink to the v4 version, essentially allowing either v3 or v4 to be installed - but maintaining the direct dependencies on actual v4 code.

[mcampa]

Investigated the CI failure — it's an OOM in tsc --noEmit (not Jest):

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Reproduced locally: pnpm exec tsc --noEmit runs ~37s then SIGABRTs.

Root cause

This PR switches src/ imports from 'zod' → 'zod/v4', but the test files (test/generator.test.ts, test/adapters/*.test.ts) still import { z } from 'zod'. TypeScript treats ZodObject from the two specifiers as nominally distinct (even though they resolve to the same runtime class in zod@4.0.14). When those mixed types flow through tRPC's deeply-generic Procedure/Router/RouterRecord machinery via OpenApiMeta, structural comparison explodes — producing TS2589 "Type instantiation is excessively deep" at one or two files, and OOMing the heap when all six src files compound it.

Bisect

State	Result
All 6 src files at zod/v4, tests at zod	OOM ❌
Only src/types.ts at zod/v4, rest at zod	25s, 3× TS2589 errors (no OOM)
All src/ and all test/ at zod/v4	✅ tsc clean in 2.3s

Suggested fix

Update the 8 test files to also import from 'zod/v4':

sed -i '' "s|from 'zod'|from 'zod/v4'|g" test/**/*.ts

After that, one real v4 API issue surfaces at test/generator.test.ts:3168 — .meta({ examples: { Lily: ..., John: ... } }) needs to become an array in v4. That's a genuine v4 semantic change, unrelated to the OOM.

---

Side note: master is also currently red, but for a different reason — #157 introduced OpenApiContactObject that fails TS2322 against zod-openapi's InfoObject (missing x-${string} index signature). Worth fixing separately.

[mcampa]

Hi @cpimhoff — thanks for the work on this! I've opened #161 which builds on your PR:

• Rebased onto current master so it picks up the contact/license fields from feat: add contact and license to GenerateOpenApiDocumentOptions #157 (which landed after this PR was opened)
• Updated test files to `zod/v4` as well — turns out the CI `tsc` OOM here was caused by mixed `zod` vs `zod/v4` imports between `src/` and `test/`. TypeScript treats them as nominally distinct types and the mismatch explodes type instantiation through tRPC's generic `Procedure`/`Router` machinery (full investigation in Follow zod guidance on supporting v4 - for users incrementally migrating from v3 #158 (comment))
• Type-only imports (`import type`) for symbols used only in type positions, per Copilot review

Closing this in favor of #161 — full credit to you for the original migration. 🙏

[cpimhoff]

I think you got me mixed up with @Sam152 😄 but I'm certainly happy to see this change!