In the past, I wrapped io-ts with OpenAPI docgen logic. This worked great: ~every network boundary type was defined once, providing runtime parse/validation and serialization, inferred static types, and API documentation all at once.

Unfortunately I didn’t get permission to open source the solution. But if I ever get bandwidth to build its spiritual successor, I’ll tackle it from the opposite direction: the OpenAPI/JSON Schema specs are very well suited to define the underlying primitives for a zod/io-ts like solution. The great thing about inverting the direction is that it defers “generating” anything to the static type system, ie there’s much less surface area for the runtime and doc schemas to diverge.

It also provides opportunities to enrich static types with more information in a general way (eg “brand” a number with its valid range, or a string as a valid email address). This would allow the benefits of runtime checks at API boundaries to be treated as static checks internally without additional/redundant internal runtime overhead.

If the spec supports a field to specify the type for a component, that would help a lot with static type generation.