Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typia/zod support #20

Closed
gotjoshua opened this issue Feb 18, 2023 · 40 comments
Closed

typia/zod support #20

gotjoshua opened this issue Feb 18, 2023 · 40 comments
Labels
good first issue Good for newcomers wontfix This will not be worked on

Comments

@gotjoshua
Copy link

any chance?

@SaltyAom
Copy link
Member

SaltyAom commented Feb 23, 2023

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.
  1. Typia requires an additional setup step and forces the developer to go TypeScript-only.

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

@SaltyAom SaltyAom added the question Further information is requested label Feb 23, 2023
@gotjoshua
Copy link
Author

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!

@SaltyAom SaltyAom added good first issue Good for newcomers and removed question Further information is requested labels Mar 14, 2023
@SaltyAom SaltyAom changed the title typia support typia/zod support Mar 14, 2023
@SaltyAom SaltyAom pinned this issue Mar 14, 2023
@murraybauer
Copy link

murraybauer commented May 6, 2023

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

@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
Copy link

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
Copy link
Contributor

kravetsone commented Dec 13, 2023

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
image

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

em-jones commented Feb 9, 2024

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

medv commented Feb 9, 2024

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

em-jones commented Feb 9, 2024

@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
Copy link

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?

@DoK6n
Copy link

DoK6n commented Jul 29, 2024

https://typia.io/docs/setup/#unplugin-typia
https://github.com/ryoppippi/unplugin-typia/tree/main/examples/bun-build

Typia can now be used in Next.js and Bun environments.
While supporting extra union types for End-to-End type safety is challenging, validation can be done before the request.

@SaltyAom SaltyAom added the wontfix This will not be worked on label Aug 30, 2024
@SaltyAom
Copy link
Member

Closing as not planned at the moment, however feels free to continue to discussion or open a new discussion in the discussion tab.

Thanks.

@jasperdunn
Copy link

jasperdunn commented Sep 5, 2024

@SaltyAom the reason I'm keen for Zod support, is being able to do cross-field validation.

Is there any possible way to do the following in Elysia atm?

t.Object({
  max: t.Number(),
  min: t.Number({ minimum: 0 }),
})

Given this TypeBuilder, validate that minimum <= maximum and that maximum >= minimum at runtime?

@jasperdunn
Copy link

Ahh I just saw beforeHandle in the docs 👍🏼

@PandaWorker
Copy link

PandaWorker commented Sep 10, 2024

Here it remains only to use the type box or write your own validator/serializer, which will be completely covered by types and JsonSchema last draft(2020-12) + OpenAPI 3.1.0 support.

For example, python has a wonderful pedantic library, you can be inspired by it, their main core is written in rust for data serialization. You can also write a kernel on growth and compile it into wasm

@ismailkarsli
Copy link

ismailkarsli commented Oct 25, 2024

In a framework that works like magic, it's sad to write validations manually. It's even sadder that by far the most upvoted issue is marked as wontfix.

@ismailkarsli
Copy link

ismailkarsli commented Oct 25, 2024

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.

I can't say anything about other reasons, you're probably right, but I should specify that Typia has a JSON Schema generation feature: https://typia.io/docs/llm/schema/

@jacksteamdev
Copy link

The creator of Zod has proposed a Standard Schema API for libraries to support instead of a single validation library.
Currently, Arktype, Valibot, and Zod support the Standard Schema, but nothing is stopping others from adopting it.

List of current libraries consuming it: https://github.com/standard-schema/standard-schema?tab=readme-ov-file#ecosystem

@kravetsone
Copy link
Contributor

The creator of Zod has proposed a Standard Schema API for libraries to support instead of a single validation library.
Currently, Arktype, Valibot, and Zod support the Standard Schema, but nothing is stopping others from adopting it.

List of current libraries consuming it: https://github.com/standard-schema/standard-schema?tab=readme-ov-file#ecosystem

Seems interesting

@jasperdunn
Copy link

Issues like this one make me feel like TypeBox is just not at all designed for UX, instead it focuses solely on performance whilst checking and parsing data.

Most use cases for me and anyone working on web apps will be form validation with custom error messages and i18n. I really think that Zod should be considered for a project like Elysia, since it's mature and well designed for custom error messages and form validation.

Looks like someone worked on a branch to try this out https://github.com/Savolus/elysia-with-zod

@kravetsone
Copy link
Contributor

Issues like this one make me feel like TypeBox is just not at all designed for UX, instead it focuses solely on performance whilst checking and parsing data.

Most use cases for me and anyone working on web apps will be form validation with custom error messages and i18n. I really think that Zod should be considered for a project like Elysia, since it's mature and well designed for custom error messages and form validation.

Looks like someone worked on a branch to try this out https://github.com/Savolus/elysia-with-zod

Typebox designed for perfomance and JSON Schema Builder

I guess our community can create new one validator that aims DX and perfomance

a lot of things of DX can be JIT'ed to improve perfomance

@rjzheng
Copy link

rjzheng commented Dec 20, 2024

need this!

@enriquecaballero-agx
Copy link

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.

I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?

I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.

While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?

I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

@kravetsone
Copy link
Contributor

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.

I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?

I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.

While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?

I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

Elysia.t is just typebox with some extends (like t.File)

@enriquecaballero
Copy link

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.
I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?
I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.
While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?
I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

Elysia.t is just typebox with some extends (like t.File)

Try passing in a raw TypeBox schema not built with t.

@kravetsone
Copy link
Contributor

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.
I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?
I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.
While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?
I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

Elysia.t is just typebox with some extends (like t.File)

Try passing in a raw TypeBox schema not built with t.

it is because elysia uses -1 major of typebox)

@enriquecaballero
Copy link

I really tried translating my Zod schemas to TypeBox because of the general performance benefits Elysia offers. But man, I couldn’t pull it off.
I thought I’d install the main TypeBox module and start from there. Then I realized I couldn’t use that official TypeBox module but had to use Elysia.t. Is that correct?
I can’t justify making my entire project dependent on a single web framework, especially a brand new one. The coupling is too much, which increases the risk.
While coupling Elysia to TypeBox is theoretically sound with legitimate reasoning, it’s not very pragmatic; I hope a Zod to Elysia.t adapter becomes available at some point. Also, why wrap TypeBox? Why not have an adapter that makes existing TypeBox schemas Elysia compatible?
I love the work done here; there’s lots of great stuff. I’ll keep an eye on how it progresses. Definitely in the future, starting fresh, I’ll give it a try, especially since I’m using Bun for all of my Node projects nowadays.

Elysia.t is just typebox with some extends (like t.File)

Try passing in a raw TypeBox schema not built with t.

it is because elysia uses -1 major of typebox)

I'm...not following? My point was that I would need to import { t } from "elysia" everywhere in my application in order to build Elysia-compatible TypeBox schemas. If this is incorrect, then please show me where I'm mistaken. I want to be mistaken. TypeBox is great in it of itself because it's generic. Can work with any web framework―I can make it work with Express, Fastify, Hono, etc. Elysia.t is exclusive to Elysia. I would be coupling my entire codebase to Elysia.

@ismailkarsli
Copy link

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

@enriquecaballero
Copy link

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

@ismailkarsli
Copy link

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

Don’t install @sinclair/typebox package too. I’m using this way and works.

@enriquecaballero
Copy link

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

Don’t install @sinclair/typebox package too. I’m using this way and works.

I would rather use @sinclair/typebox as the dependency in my code and then use the schemas defined with @sinclair/typebox with Elysia. NOT the other way around.

@kravetsone
Copy link
Contributor

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

Don’t install @sinclair/typebox package too. I’m using this way and works.

I would rather use @sinclair/typebox as the dependency in my code and then use the schemas defined with @sinclair/typebox with Elysia. NOT the other way around.

Override typebox version in elysia

@enriquecaballero-agx
Copy link

Just import from “@sinclair/typebox” package without installing anything. It should use Elysia version of Typebox. @enriquecaballero

I tried that...

Don’t install @sinclair/typebox package too. I’m using this way and works.

I would rather use @sinclair/typebox as the dependency in my code and then use the schemas defined with @sinclair/typebox with Elysia. NOT the other way around.

Override typebox version in elysia

… Can you elaborate be more specific? As I said in my original comment, I tried to make this work and I tried various things. It’s not so trivial.

@sinclairzx81
Copy link

sinclairzx81 commented Dec 24, 2024

@enriquecaballero-agx @enriquecaballero @kravetsone @jasperdunn @rjzheng

I hope a Zod to Elysia.t adapter becomes available at some point.

A new TypeBox library is available that enables the integration of Zod and Valibot into Elysia. This library works by transforming Zod and Valibot types into TypeBox-compatible schematics (i.e., JSON Schema). It allows Zod and Valibot validation to be accelerated by the TypeBox compiler and makes these libraries compatible with OpenAPI/Swagger.

Project: https://github.com/sinclairzx81/typebox-adapter


Example

The following creates an Elysia route and configures parameters using TypeBox, Zod and Valibot. Type inference is preserved.

TypeScript Link Here

import { Box } from '@sinclair/typebox-adapter'

import { Elysia, t } from 'elysia'
import z from 'zod'
import v from 'valibot'

new Elysia()
  .get('/remix', ({ params, query, body }) => {
    const { x, y, z } = params // from TypeBox
    const { a, b, c } = query  // from Zod
    const { s, t, u } = body   // from Valibot
  }, {
    params: t.Object({
      x: t.String(),
      y: t.Number(),
      z: t.Boolean()
    }),

    query: Box(z.object({
      a: z.string(),
      b: z.number(),
      c: z.boolean()
    })),

    body: Box(v.object({
      s: v.string(),
      t: v.number(),
      u: v.boolean()
    })),
  })
  .listen(3000)

This project is brand new, with work continuing through 2025. I anticipate additional updates will be required when Zod 4 is released, and there are considerations to include other libraries like EffectTS in the future. If you use this project, feel free to submit issues or provide general feedback.

Hope this helps
S

@ismailkarsli
Copy link

@sinclairzx81 Do you think there will be a chance to add Typia support in the future?

@kravetsone
Copy link
Contributor

@sinclairzx81 Do you think there will be a chance to add Typia support in the future?

typia support is hard

because it AOT with builder plugin

@kravetsone
Copy link
Contributor

@enriquecaballero-agx @enriquecaballero @kravetsone @jasperdunn @rjzheng

I hope a Zod to Elysia.t adapter becomes available at some point.

A new TypeBox project is now available, allowing you to integrate Zod and Valibot into Elysia. This project transforms Zod and Valibot types into TypeBox-compatible schematics (i.e., JSON Schema), enabling acceleration by the TypeBox compiler (matching TypeBox's speed) and compatibility with OpenAPI/Swagger.

Project: https://github.com/sinclairzx81/typebox-remix

Example

The following creates an Elysia route and configures parameters using TypeBox, Zod and Valibot. Type inference is preserved.

TypeScript Link Here

import { Box } from '@sinclair/typebox-remix'

import { Elysia, t } from 'elysia'
import z from 'zod'
import v from 'valibot'

new Elysia()
  .get('/remix', ({ params, query, body }) => {
    const { x, y, z } = params // from TypeBox
    const { a, b, c } = query  // from Zod
    const { s, t, u } = body   // from Valibot
  }, {
    params: t.Object({
      x: t.String(),
      y: t.Number(),
      z: t.Boolean()
    }),

    query: Box(z.object({
      a: z.string(),
      b: z.number(),
      c: z.boolean()
    })),

    body: Box(v.object({
      s: v.string(),
      t: v.number(),
      u: v.boolean()
    })),
  })
  .listen(3000)

This project is ongoing, with work continuing through 2025. I anticipate additional updates will be required when Zod 4 is released, and there are considerations to include other libraries like EffectTS in the future. If you use this project, feel free to submit issues or provide general feedback.

Hope this helps S

Fine! But i guess remix not so good name because react-remix))

also did u want to work on new validation library? Like Typebox but with more DX and JITed

Like Zod but really faster (for example compile string().maxLength(8, "error").trim() to a function)

JSON schema needed but can be generated by remappers from internal

@ismailkarsli
Copy link

ismailkarsli commented Dec 24, 2024

@sinclairzx81 Do you think there will be a chance to add Typia support in the future?

typia support is hard

because it AOT with builder plugin

I’m currently converting schema() function output (which is JSON schema) to Typebox schema. But the lack of first-party support bothers me. But it works.

@sinclairzx81
Copy link

@kravetsone Hi,

Fine! But i guess remix not so good name because react-remix))

I agree. Remix was the working title used during development, but I guess it's not as descriptive as it could be. I have republished under a the more formal name @sinclair/typebox-adapter.

github: https://github.com/sinclairzx81/typebox-adapter
npm: https://www.npmjs.com/package/@sinclair/typebox-adapter

Thanks for the feedback :)

@kravetsone
Copy link
Contributor

@kravetsone Hi,

Fine! But i guess remix not so good name because react-remix))

I agree. Remix was the working title used during development, but I guess it's not as descriptive as it could be. I have republished under a the more formal name @sinclair/typebox-adapter.

github: https://github.com/sinclairzx81/typebox-adapter
npm: https://www.npmjs.com/package/@sinclair/typebox-adapter

Thanks for the feedback :)

Great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests