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!