typia/zod support

[gotjoshua]

any chance?

[SaltyAom]

I have this consideration I have previously with Zod/io-ts/typia.

For one, I want to put out as fast as possible while still balancing with Quality of Life, Typia introduces two mature problems that make me not support Typia (at least for now).

1. It shouldn't only just check the type, the reason I pick TypeBox is that it also supports OpenAPI Schema which is important to make a standard production-grade REST API server, and the ability to specify server specs and generate documentation of fly.

Many have asked why Elysia uses type box instead.

1. Typebox is built around OpenAPI which made the Swagger plugin possible.

2. Typia requires an additional setup step and forces the developer to go TypeScript-only.

3. The cost of adding an extra union type to support End-to-End type safety is likely very high and complex, For one to make this full type-safety work, Elysia is using depends on LocalHandler, LocalHook, ElysiaRoute TypeRouteToEden, and CreateEden which is highly a complex type consist of over 600 loc for typing only, at the moment the type inference isn't as fast as it should be but if we manage to add one more union type for Typia, it's likely to have a problem with the performance of type inference.

And in regard to performance, TypeBox is using AoT compilation to improve performance

Summary

We may support Typia someday or might not support Typia at all (depending on the situation that may unfold in the future), but for now, we have no interest or priority to support Typia at the moment, and if we have to support 2nd validation library one day, it's likely that Zod will be our priority next.

I will leave this issue open for discussion, feel free to ask more questions if the answer is not clear.

[gotjoshua]

very satisfying answer, thanks @SaltyAom !

I also wasn't thrilled with the ttsc business and very much enjoyed my approach to typebox and zod.

thanks for all your work and generosity!

[murraybauer]

Whilst Typebox for OpenAPI support is a nice 'feature', these days in terms full stack javascript development (elysia is node.js) it's not always needed given the focus on server actions which use typescript types, so adding validation to exsting types using typia I feel is a nice solution.

I don't really see that big a difference DX wise from Typebox to Zod.

[mildronize]

@SaltyAom I've found the interesting repo: https://github.com/decs/typeschema for Universal adapter for TypeScript schema validation.

They support various type of data validation. It might be help.

[marbemac]

FWIW Zod type-checking performance has historically been pretty poor as projects increase in complexity. However, I have not checked on a real-world project lately. Most recent deep dive I've found -> https://dev.to/nicklucas/typescript-runtime-validators-and-dx-a-type-checking-performance-analysis-of-zodsuperstructyuptypebox-5416

[kravetsone]

I don't really see that big a difference DX wise from Typebox to Zod.

Unfortunately, there is a difference in DX... The TypeBox does nothing more than the JSON SCHEMA allows itself to do
Zod has excellent chainable validators/transformers, which greatly simplifies development

By the way, there is an interesting alternative to Zod - Valibot (Site, Github)

@SaltyAom I've found the interesting repo: https://github.com/decs/typeschema for Universal adapter for TypeScript schema validation.

They support various type of data validation. It might be help.

It's impressive! But we need to make sure that we don't lose anything from integrating this
and what if elysia has its own contribution to the type system

t.Object({
    avatar: t.File({
        type: "image",
    }),
}),

I'm not ready to give it up! It's too convenient

[em-jones]

I don't really see that big a difference DX wise from Typebox to Zod.

Two things that "jump out" at me are:

• branded types

const NonEmptyString = z.string().min(1).brand("NonEmptyString");
type NonEmptyString = z.infer<typeof NonEmptyString>;

const greet = (s: NonEmptyString) => z.string().min(1);

This sort of approach is handy for protecting your system from invalid data at the type level.

• ubiquity... Not to say that this alone should be a deciding factor, but a tool's popularity can be a benefit

[medv]

Saw the trpc plugin and decided to give elysia a go, sure enough spotted the "compile" import in the example only after hitting a type error passing zod schemas to the procedures. Definitely a non-starter, would have been an instant switch from fastify otherwise. Even for a greenfield project like the one I wanted to try elysia for, many folks already have their big bag of zod tools and patterns they would like to slingshot a new project with. For example https://github.com/chrishoermann/zod-prisma-types is alone responsible for dozens if not hundreds of hours saved during prototyping phase (not to mention react-hook-form and its zodResolver on the other side). The switch over to a proprietary validator is a tall ask and definitely stunts this project.

Sorry, I know how this probably reads, but I've a good feeling that many people are not bothering to say anything and instead have just gone to use something else.

[em-jones]

@medv 's sentiment:

Definitely a non-starter, would have been an instant switch from fastify otherwise.

This is an anecdotal scenario of why ubiquity can be meaningful.

(not to mention react-hook-form and its zodResolver on the other side).

To their point... what's stopping this from being an extensible interface? (besides the obnoxiousness that might come from some additional generic typing)

[fernandortec]

https://github.com/turkerdev/fastify-type-provider-zod

Can this be of any help?
This package can create swagger docs using all Zod schemas and Fastify, would an implementation like this solve the issue of generating the open API schema?