Open jedwards1211 opened 1 month ago
I think a better compromise would be for builtin checks like .min(1).max(128).url()
to all be tried, since the goal is to receive all of those error messages, but for custom refinements to be skipped after an error unless we explicitly opt into it. Would be a good breaking change for v4.
Especially considering that builtin checks don't create a chain of Zod nodes under the hood like custom refinements do, I think a behavior distinction between builtin checks and custom refinements makes sense.
Does https://zod.dev/?id=abort-early match your use case?
@sunnylost of course I can work around this issue in various ways, including the fatal
flag, but I am trying to advocate improving the API to where we don't have to work around it, and it's less surprising.
I don't personally understand the benefit of the existing behavior, but if it's kept that way, the types should at least be fixed to where the same type is used for the value argument to each
.refine
predicate in the chain, instead of the output of the previous.refine
.I think the existing behavior is especially unfortunate in cases like this:
Surprise, nope:
I don't think anyone would naively expect Zod to try the refinement on non-URLs, since the behavior of other Zod nodes besides refinements is to abort the chain if one node fails parsing.