Change typing library?

[dblatcher]

Comment on the dev/dev channel from George B :

• io-ts, the library we're using to perform runtime type validation of incoming data from Google sheets, is very powerful. But, it's tightly coupled to fp-ts which assumes a good handle on functional programming techniques to perform most operations. Second to that, a large part of io-ts's functionality is in the experimental stages still

On a recent mobbing exercise we did, a few people compared runtime type validation libraries. io-ts was considered, and generally found to have quite a steep learning curve. There are some notes here : https://docs.google.com/document/d/1gH5x6vReNsVYP8Sf0enIKaIjNVaru9TQxWHHcbI4fLU/edit

Another alternative library considered in the mobbing was zod.dev - it had fairly good developer experience and was pretty powerful.

I'm considering whether this is a good opportunity to consider a refactor to use Zod in place of io-ts? I'm generally quite wary of this kind of refactor, hoping the grass is greener, which is why I wanted to gather your thoughts. What I would hope to get from a refactor to Zod is:

• shallower learning curve, not requiring to learn FP techniques and concepts to be able to interact with our type system
• more features in "stable" state
• clearer documentation

[dblatcher]

I tried zod on a personal project over the weekend I think it could be a good fit for our use case. The basic concept is that you build a Schema object using the library and can then the library 'infer' function to generate a typescript type describing the Schema. This isn't dissimilar to what io-ts does , but the Schema definitions are closely modelled on typescript features and concepts (eg array, union, `object) - as George said, this makes it much easier to learn coming from typescript.

A Schema object has methods to (inter alia) parse an object to test if it matches the schema and can be cast as your type.

If it doesn't match, there is a structured ZodError object that provides usable data about why the object doesn't match. This could have potential use extending the error logging to say which rows failed validation and why (EG "Row 7 (morning-mail) has empty column AC (Braze campaign)

This seems a better approach than the one we have with io-ts, which relies on unsafely casting the unverified