How to use `zod` in a clean architecture setup?

Hi @colinhacks - great lib!

I would love to use this in our project but right now I am not clear on best to structure the code so that the entities do not end up directly depending on zod.

Ideally the core entities should not depend on anything, here since they are defined using a zod object that seems impossible?

Thanks again!

[akomm]

• You can inverse the dependency, so type Item is not derived from const Item, but const Item is typechecked against type Item.

type Item = {
  id: string
}
const Item: z.Schema<Item> = z.object({id: z.string()})

• You can map schema API simply via a function & interface, hidding zod:

// use interface
type ParseItem = (v: unknown) => Item
const parseItem = (v: unknown) => Item.parse(v)
// not parseItem = Item.parse because of
// https://github.com/colinhacks/zod/issues/808
// and also because parse has more than 1 argument, even though optional

I guess everything else, how to make the layers should be derivable, or else make specific questions. I’d recommend, if you go FP direction to actually use Item.safeParse(v) and return an actual Either<L, R> or Result<E, A>

[akomm]

z.Schema is abstract interface, does not have API for the specific types.

The solution to your problem depends on context of usage. For example you don’t need to use z.Schema, as long as usage of ZEnum is somehow constraint to the type.

For example:

const parse = (v: unknown): IUnion => ZEnum.parse(v)

This will fail type check if ZEnum is not compatible with IUnion. You will see the problem on use, down the line, not directly on ZEnum in this case.

Its in this case not exhaustive, but the moment you remove a value from IUnion, wherever you referred to it will be invalid and fail type-check, whenever you add something, ZEnum.parse will fail, if it misses the value.

You can also create exhaustive APIs like usualy using IUnion too.