> And we already have runtime validation libraries to cover that validation step.

Right, but now my type information for inbound data must be in two places: the typescript type, and the validation schema. And heaven forbid I make a mistake and those two become out of sync.

Yes, I can use something like zod to define a schema then infer the type from it, but those inferred types are often … suboptimal to work with.

Zod is great, why do you think it is suboptimal ?

I love zod and use it daily.

It is also the most frequent thing where junior developers get stuck. TS tooling doesn't make it very easy to work with large extracted types though it is head and shoulders above other mainstream languages. The error messages often become incomprehensible walls of text once your types are Complex enough, and then tsserver will just truncate the type info in pop overs making them useless.

I am personally OK to live with all of the above. My single issue with zod is that it is not easy to use if you don't own your types. If your types are coming from a third party lib you don't have an easy path to derive runtypes from them. If the concept of runtypes was supported by the compiler itself, this could have been possible but as a userland library zod can't handle this easily.

Why would a ts-native offering produce better error messages when it comes to complex types? That is an issue with TS in general (or rather, with complex types in any typesafe language).

No.

Imagine a Zod schema like:

const UserLocation = z.object({ address: Address, coords: Coords })

where Address, Coords are other zod schemas.

Now if I infer a type like:

type IUserLocation = z.infer<typeof UserLocation>

Th inferred IUserLocation is something like:

type IUserLocation = { address: { city: string, country: string, ... }, coords: { lat: string, long: string } }

The extracted type does not refer to separate Address, Coords type, it is a single complex type that represents the complete nested structure.

So if I do something like:

const userLocation: IUserLocation = { address: { ... }, coords: { lat: 0, long: 0 }}

The error message is complex because it (effectively) says that coords.lat was expected to be a string from IUserLocation["coords"]["lat"] but it was number

However, if I define a ts interface directly:

interface IUserLocation { address: IAddress coords: ICoords }

now any errors reported against this interface will be more comprehensible because they will (effectively) say that coords I am providing does not comply with ICoords.

This is a contrived example, but this becomes more complex when you have deep compositions of zod types.

This issue of typescript not using well named intermediate types when types are "extracted" from schema definitions like zod is what makes the error messages complex.

This would not apply if typescript was to provide runtime type checking for interfaces defined in typescript (as opposed to them being inferred) because ts will have a way to "know" about these intermediate types. Then the type errors would not have to be always reported against the complex top level type.

That's a good point.

I just realized that I am working around this problem by explicitly setting a `z.Schema<...>` type: [link redacted]. The reason was to retain JSDoc comments on the types, but I guess this was another positive side effect.

In any case, I agree with you that there is room for improvement.

Ah ok. However, typescript is mostly smart enough to propagate comments [1] from zod schema properties to inferred types on its own.

Thanks for maintaining kanel btw. We used to use this in a previous role alongside knex. It was very useful.

[1] https://lorefnon.me/2022/06/25/generating-api-docs-for-zod-t...

Hah, I wasn't aware! I think that must have been fixed after I tried it the first time because I definitely concluded that it was necessary back then. And thank you for the kind words!

I found Zod a lot easier to use once we were given the "satisfies" keyword. I still basically have to write my schema twice (I don't mind this) but I can ensure the two are tightly coupled. A change to either one will show a compile error in the right place:

interface Person { firstName: string; lastName: string; }

const PersonSchema = z.object({ firstName: z.string(), lastName: z.string(), }) satisfies z.Schema<Person>;

Interesting! I'll probably start doing that. I hadn't connected the satisfies keyword to this problem, but it seems like a good solution.

My complaint about writing the schemas twice isn't the busywork (which is, like, annoying, but whatever I'll live). But the concern about small discrepancies between the two causing problems later.

I'll definitely use this going forward.

I like a lot of things about zod (it's what I use when I need to do this kind of validation), but when I was working with a mildly complicated schema the type that z.infer<Schema> produced wasn't great for me.

When I produce a type definition for a nested schema, I'll produce types for individual pieces.

So

type Schema = { foo: Foo; bar: Bar; baz: Baz[]; }

type Foo = { red: Color; white: Color; blue: Color; }

type Color = { r: number; g: number; b: number; }

type Bar = {...} type Baz = {...}

I couldn't find a clean way to decompose the type that z.infer<Schema> produced. It would give me a single type object that was deeply structured. For a pretty flat-simple small schema, z.infer<> was totally fine.

For the more complicated schema it wasn't _terrible_, I still used it. I made it work, but it definitely wasn't the dev experience I was hoping for.

I think something that went the other way would be much preferable for me. I'd rather define the typescript type, then have some validate<Schema>() function that was available to me.

Basically, I think it's _easier_ to get a generated validate() function to play nicely with the rest of my code, than it is to get the inferred type to play nicely with the rest of my code.

Use objectSchema.shape.xxx to access the nested schemas and infer on those.

Except for the fact that usually there is not just one single typescript agent working within itself, for which you don't need validation. There are many cases in which you need to verify some object, anything that does not come from your code i would argue is untrusted, I come across this almost daily, it would be absolutely fantastic to just have a way to check does this object conform to this type? Instead, i need to use some external dependency, effectively duplicate my type definitions and add yet another place to introduce bugs.

Just use a run-type transformer like typia, hooked right into typescript-compile. Get your runtime type validators generated from nothing but the typescript definitions.

Alternatively, use a runtime validator the provides good type inference out of the box so you're still only declaring your types once.

I would recommend `zod` as a good typescript schema runtime validation library as well. It does require strict type checking to be on however.

I use zod but it's a workaround. I use non standard syntax to define types.

If typescript emitted type information, we'd be able to automatically get runtime validation at the boundaries of our apps.

Alternatively, io-ts is more performant and has been around for a while longer. Although it does have a more functional interface.

I like typia for doing codegen basically in the way this request is asking: it hooks into the typescript API to create runtypes from plain old typescript

And presumably you need to also trust your third party libraries, unless you're also compiling them from TypeScript. Right?

And even if you are--that might also involve ensuring their tsconfig.json is compatibly similar to yours. Otherwise the compiler might allow them to return null instead of the object they say they return, among potentially many other "gotchas" that are bound to appear.

EDIT: Though I think I do agree with you, ultimately. Runtime type checking imposes non-negligible costs and complexity that still theoretically should be able to be guaranteed at compile time for cases where one isn't validating untrusted user input.

Yes, you need to trust your third party libraries, better check them. Otherwise they may steal your data, inject XSS, mine cryptos, have memory leaks or faulty logic.

> And we already have runtime validation libraries to cover that validation step. So many of them.

Did you read the article? I think that's the point. The premise is Typescript should be responsible for solution to runtime validation against Typescript not third party hacks.

It would be nice if the runtime validation was an ecmascript feature designed in such a way that typescript could infer the types for them automatically... Such as

    schema Example { ... }
    cosnt example: Example = new Example(unkonwnData)

Where a schema applied runtime validation based on declarative syntax and which typescript could use to derive a `type` from

That boundary validation is where that kind of reflection would be useful! And it's a problem that (nearly) every useful application has to face.

Well that, and getting rid of the silly "must be able to strip types without processing them" design ideology would also enable stuff like typeclasses.

> Once it's in there, it is type safe if you used TS to compile your code to JS […]

To the extend that TS's type-system is unsound, and everything may crash at runtime at random anytime.

In a language with a sound (or even sound modulo escape hatches) type system, I would agree. But Typescript can and will lie to you at compile time, and it's much harder to guard against this than it should be.