Designing the perfect TypeScript schema validation library

FWIW, runtypes is now part of my standard utility kit (along with utility-types[0]) for every TypeScript project I start. I don't leave home without it, and (AFAIK) it checks off every box mentioned as a problem by the author of the article.

At my employer, I just whacked it straight into our new API codebase on day one and people took to it immediately. It's great, great stuff.

[0]: https://github.com/piotrwitek/utility-types

While I think this is pretty cool, given his use case (wanting to use a strongly typed client and server), I can't see why one wouldn't just use GraphQL with TypeScript on both the client and server. I've done this and I love it:

1. Define the GraphQL interface with GraphQL's typedef language. GraphQL then takes care of validating all the request and responses at runtime.

2. Use something like https://github.com/dotansimha/graphql-code-generator to generate all your TypeScript types from your GraphQL schema. Place these types on your resolvers and then you get compile-time type checking.

3. Since GraphQL actually exposes your schema as part of the endpoint, clients can use the same tool to keep their TypeScript types in sync, and get the same typing benefits when writing the client code.

I guess it's something in the air! Given the popularity of the other libraries, it's surprising that there's isn't an optimal one.

And yeah, unless you've gone down the rabbit hole of type safety obsession, it's hard to understand the necessity of this. I like that you specifically call out REST API validation in your docs...the difficultly of type safe API implementation was what drove me to build zod.

I'm using Zod plus a hand-rolled codegen tool to implement an end-to-end type safe RPC API that validates all data at runtime AND generates a statically typed Typescript SDK for use on the client.

PS If people like the sound of that I might publish that too. Let me know if it sounds interesting.

The assignment to class properties reminds me an awful lot of stuff I've seen in Python, particularly in Django/REST Framework.

But the class wrapping thing would just break my brain every time I tried to use it. Calling plain functions just feels a lot more natural to me.

I hope you'll give me the opportunity to try to convince you otherwise.

I understand the context of this is that io-ts puts an onerous emphasis on FP concepts and data structures. But FP principles, when applied in an effective and usable way, are quite good. The make it easier to reason about and maintain code.

One such principle is that a "function" with no parameters is a good sign that it will cause some kind of side effect. I sort of hinted at this when I questioned the design, when I said that it wasn't clear to me whether calling these functions was producing new instances and whether those new instances affect behavior.

I would also argue that leaving room to parameterize primitive types is leaving room to make a drastically more complicated API in the future. A `string` with "options" suddenly becomes its own sub-API.

While io-ts is more complicated, once learnt its API is more predictable. A `Type` is a value. An `interface` (or similar) type is a `Record`. Always. `Type`s can be augmented/composed/etc (and you may provide a function that accepts one or more `Type`s as parameters to accomplish that), but they always resolve to a value. The value can be reused without concern about side effects.