Elysia 1.3 feedback

[SaltyAom]

Hii~ Do you miss me?

We would like to hear your thoughts on how is your experience with Elysia 1.3.

How do you think Elysia is going? Here are some for starters.

• What should we focus on?
• What do you think is missing?
• The good, the bad, and the ugly.

You can suggest anything, like sharing your experience with Elysia.

Have a nice day!

[kravetsone]

Main elysia issue is maintability / feedback on issues. But currently you close most of the issues and bugs! This is so amazing.

About features... I can propose some APIs later

Also maybe we can create an new validation library which will improve DX and perfomance for elysia (but library should be separated)

I guess typebox is not so cute in use (ohh how zod custom validation errors vs typebox...)

We should research in this area and maybe create something our own

Also i ofter see errors with drizzle-typebox and elysia in one repo with [type symbol] issue... it's sad (but it not so elysia issue)

#773

Also... lets make test coverage both aot: true | false (Maybe process.env.ELYSIA_AOT_DISABLE for easy test running). Because most of the elysia lifetime aot: false isn't priority but it didn't mentioned as "bugly experimental feature without enough tests coverage"

Also i guess node adapter not well tested. We should coverage more and more elysia usecases

I recommended Elysia to people, but they often stumbled upon bugs and left (even according to the examples in the documentation of the beginner's guide!)

[abaena-gisce]

Maybe Elysia could validate things following the Standard Schema.
This will let user a lot of flexibility to use any validation library that follows this standard. For example: ArkType2.0, Zod, Valibot, etc.
You can look for the full compatible list with this standard: https://github.com/standard-schema/standard-schema?tab=readme-ov-file#what-schema-libraries-implement-the-spec
I don't know what are the implications of these changes, but everyone wants flexibility. Is the best way to expand to the world 😄

[kravetsone]

Maybe Elysia could validate things following the Standard Schema. This will let user a lot of flexibility to use any validation library that follows this standard. For example: ArkType2.0, Zod, Valibot, etc. You can look for the full compatible list with this standard: https://github.com/standard-schema/standard-schema?tab=readme-ov-file#what-schema-libraries-implement-the-spec I don't know what are the implications of these changes, but everyone wants flexibility. Is the best way to expand to the world 😄

standard schema is good but it misses json schema generation support which elysia mostly use for features (like docs or sanitize)
Maybe we can omit in and introduce
first-class validators and spec

[heiwen]

Right now it seems that Hono + oRPC / tRPC are pretty much the default choice for type-safe backend development.

I would ask the question “what is Elysia missing to become the default instead”?

Some more or less random thoughts:
1/ Native TanStack query integration for Eden
2/ Contract-first development option
3/ Framework integration for NextJS / RR / … (/api routes, ServerActions, RSCs)
…

I also have to agree that we had a lot of trouble with TypeBox in the context of drizzle. While not exactly Elysia’s or Typebox’s fault, many people use drizzle and it does impact the experience quite a bit.