What validations/refinements should be in "core"?

[scotttrinh]

It seems like we get a lot of issues asking for extensions to the built-in class of validations, and I wondered what the general philosophy we want to take here is.

In my view, I feel like refine is the right level of abstraction to allow each consumer to define their own set of validations that they find useful, but I can sympathize with those whose usage of Zod include heavy usage of validation logic and it's slightly more ergonomic to have them as methods on the types.

I'd love to be able to point issue authors and PR authors at some idea of our general feelings here, but I don't want to impose my minimalist view if I'm in the minority, or if there is a helpful heuristic as to which kinds of validations we want to encourage people to author.

[carlpaten]

This is a really important topic!

My bias is towards keeping core smallish, and make it easy to extend - provide code examples, etc. However in our own zod practice at Medzy we haven't yet found a pattern for extending zod that really resonated with us aesthetically.

[Brian-McBride]

I don't mind refine at all. I can see where people want a proper place to stash metadata though. I made a lib that uses a wrapper pattern and it's ok. But that's not going to be as great with refine. But that is an edge case anyway.

[rubber-duck-software]

Having each consumer write their own refinements using refine is certainly workable, however I cannot see an ecosystem of zod refinement packages growing up out of this pattern. It might help us if it was easy to publish and consume a set of zod types/refinements. For example, someone could create a set of zod types/refinements for immutable-js. Another example might be a set of date refinements monthEquals, yearEquals, etc.

[scotttrinh]

Is there something you are imagining that the zod core library would need to do in order to better support an ecosystem of refinements? It seems like exposing refine should be enough, but I'm curious if you think there is something more that we should do here.

I'm imagining this since it's already possible:

import { z } from "zod";
import { emoji } from "some-ecosystem-library";

export const emojiOnlyString = z.string().refine(emoji);

[carlpaten]

Internally we're considering something like import { z } from "our-zod-ext"; and have all the extensions defined. This doesn't require any special support from the core library but also it isn't composable.

For composability we could have a polyfill-like approach but that's putting a lot of trust into the hands of plugin authors not to modify core Zod and each other. I'm concerned about attacks such as what happened with flatmap-stream.

[scotttrinh]

Yeah, honestly I feel like exporting refinements is best due to exactly those reasons: composibility and being able to trust the z object is the one coming from zod. I can imagine ecosystems that also export transformers and full schemas as well.