You might be interrested to take a look at typematic

[ecyrbe]

Hello,

Someone showed me your project. it's really interresting.

I did something a little different with my library Typematic : https://github.com/ts-api-spec/typematic

it's using some Higher Kinded Types trick to not tie the OpenApi Spec to any validation library at compile time/runtime.

The advantages over the tRPC approach :

• someone else can implement an adapter without modifiying the core library or the core library being aware of the validation functions used in those libraries
• allows to validate schemas that don't have a validate function inlined in the schema (like @effect/schema, json-schema or json-types)
• allows to have errors properly typed
• there is no clashing name possible (example: one lib using validate() to not throw while another lib do)
• i have yet to find a library where this approach don't work

Some disadvantages :

• you need to declare your type adapter somewhere in your document format to tell it what adapter to use (for example in your form decl, or your api spec decl). Meaning you need some form of integration for each use case. Typematic does it by being a declaration for api spec and you can set your adapter (called ShemaType) at any stage of the document, so you can still mix different validation libraries in the same document.

Maybe typematic can give you some ideas on how to have your cake and it up too.

Keep it up!

[decs]

Hey, @ecyrbe! typematic seems exciting and aligned with the vision I have for the validation libs environment as well 😃

I started looking at increasing support to other libs a couple days ago and hit this issue you mentioned. Not every schema object includes their validation functions.

The approach I ended up choosing was to rely on optional peer dependencies. That's based on the assumption that if you're passing a schema from a specific validation lib, then that lib is installed locally and therefore could be reused by typeschema for free. About the disadvantage you listed, I solved it by including business logic to auto-determine which lib the schema came from. It's a tradeoff for sure, since there's some performance hit due to this additional step, but it's worth it for keeping the API simple. There's also a maintenance cost, but I can mitigate it by limiting support to only "popular enough" validation libs.

I feel that the design pattern I implemented for adapters could be more robust/type-safe, so I'll look into the Higher Kinded Types concept you mentioned. Thanks for the feedback and the tradeoff discussion!