Support for zod/v4

[theshadow27]

Zod is preparing for the v4 release, and v3.25+ can use import {z} from "zod/v4" to get access to the new API.

Since typemap hard-imports import * as z from "zod", the Zod and TypeBoxFromZod don't work with v4.

Is there a plan for a TypeBoxFromZodV4 or something? You open to a contrib?

Edit: Hopefully you're open to a contrib... see #34 .

My use case is a bun monorepo with an Elysia server, but I had already typed everything in "zod/v4" before I realized that it wouldn't work. Since Elysia relies on TypeMap types, a conversion is necessary to leverage the nice fluent API that Elysia provides while keeping my single-source-of-truth types intact.

Awesome library btw - if it weren't so well structured no way that this could have been added in < 5h. 👍

[HuakunShen]

@theshadow27 Are you trying to use zod schema in Elysia?
I also have a bunch of zod schemas already defined in zod v4, and is considering using typemap to convert zod to typebox.
But zod v4 is blocking me.

And zod v4 stable is already released. You may want to change the version in your PR.

[theshadow27]

@theshadow27 Are you trying to use zod schema in Elysia?

Yes.

I also have a bunch of zod schemas already defined in zod v4, and is considering using typemap to convert zod to typebox.
But zod v4 is blocking me.

Me too.

And zod v4 stable is already released. You may want to change the version in your PR.

It should be set to the minimum compatible version as a peer dependency so that the most versions of zod will work. V4 is bundled with v3.5.x so that's what I used.

Still waiting on feedback from @sinclairzx81 on the PR. Almost everything is working, but I am stuck on template strings. The reason is that z4, unlike z3, doesn't capture the types of template parts - it holds it as a plain template string w/o type info. While it can be re-split into parts, exact type info is lost or at least widened substantially.

Template strings are critical for Elysia (at least for me) because of path parameter typing. Maybe it is possible to merge without, but the implementation would be incomplete.

[sinclairzx81]

@theshadow27 Hey, sorry for the delay on this.

I will be getting back into this PR as soon as I can. At this stage though, I am working through some very heavy upstream TypeBox updates (which I am trying to get out for September), but where these updates will have implications for the TypeMap project, Elysia + several other projects that leverage TypeBox.

The Z4 update will go through it looks pretty good, but want to make sure the upstream work in TB is gets full attention before considering things downstream (which also relates to other projects like Codegen)

---

TemplateLiteral Mapping

So just to offer a quick review to the TemplateLiteral (without going too deep). The mapping looks ok and it is great you've found the correct TypeBox types for this (nice work!). I haven't looked at the Zod 4 implementation in detail so trust your implementation here, but looking at the current mapping will need to replace the current usage of TS mapped types for tail call recursive mappings.

I'll detail that below (it should be a quick change)

TTemplateLiteral Signature

The TTemplateLIteral type in TypeBox has the following signature.

interface TTemplateLiteral<T extends TTemplateLiteralKind[] = TTemplateLiteralKind[]> extends TSchema { ... }
//                         ^ T is sized tuple structure

So we need to ensure the parameter to this type is a sized [...TTemplateLiteralKind[]]

Current Mapping

This PR implements the following mapping (mapped types)

type TFromTemplateLiteralParts<Parts extends z.core.$ZodTemplateLiteralPart[]> = 
  { [K in keyof Parts]: TFromTemplateLiteralPart<Parts[K]> }[number][];

Revised Mapping

This type should be re-written as a accumulated + tail call recursive mapping where we accumulate TTemplateLiteralKind in Result.

type TFromTemplateLiteralParts<Parts extends z.core.$ZodTemplateLiteralPart[], 
  Result extends t.TTemplateLiteralKind[] = [] // <-- accumulate here
> = Parts extends [
  infer Left extends z.core.$ZodTemplateLiteralPart,
  ...infer Right extends z.core.$ZodTemplateLiteralPart[]
] ? TFromTemplateLiteralParts<Right, [
  ...Result, 
  TFromTemplateLiteralPart<Left>
]> : Result // <-- result here

With the runtime symmetric mapping updated to reflect the type level logic.

function FromTemplateLiteralParts<Parts extends z.core.$ZodTemplateLiteralPart[]>
  (parts: [...Parts]): TFromTemplateLiteralParts<Parts> {
   return parts.reduce((result, left) => 
     [...result, FromTemplateLiteralPart(left)], [] as t.TTemplateLiteralKind[]) as never
}

Rationale

The reason for doing it this way is mostly because TypeScript has a better time scaling (more depth) for sized tuple structures vs mapping over keys. Also mapped keys in TypeScript can explode with "instantiation too deep" errors if TypeScript cannot prove the keys to be a finite set. Mapped types also depth + 1. Using the tail call recursive type mitigates that issue where tuples can over ever be sized. but also allows the the TypeMap to learn on general TS depth allowances for tail call recursive types (TCO - call stack - depth trampoline).

---

Other than that, things are still looking good here. I will get to this PR as soon as I can, but given the level of updates going on for the next revision of TypeBox, I going to need to focus on that before focusing on how things ultimate map through here, but this PR is totally on the right track.

Again, sorry for the delay and thanks again for submitting this PR. Your update is important. I will return to this as soon as I can. If you want to discuss other aspects of this PR / TM implementation details, feel free to ping a comment and I'll address when I can.

Thanks again!
S

[WillFP]

Any updates on this? I've got the same use-case