Zod validator calls refine and ignoring other validators

[hexwit]

Hi,
I need to validate presence of url, and that it has valid format.
I know about url() validator, but I will need more fine grained checks.

So I tried to use refine().

validate: zodResolver(
    z.object({
        url: z.string()
            .min(1, "This is a required field")
            .refine((value) => {
                try {
                    new URL(value);
                    return true;
                } catch {
                    return false;
                }
            }, "Invalid URL")
    })
)

for some reason zod ignores '.min' validator and calls always refine().

Is this an issue or I just don't understand something?

Thanks.

[JacobWeisenburger]

Zod tries to run all of the validation "chain", so that you would get as many of the errors as possible. Therefore, it will run a refine even if the prior checks failed.

[jedwards1211]

I'm well-versed in Zod features, and I know how to work around this with superRefine, I would just rather not, because it's more cumbersome and less readable than better default behavior would be. My argument is that being able to write z.string().url().refine(s => new URL(s).protocol === 'mqtts:', 'must be an mqtts: url') would be much more convenient for everyone overall. We should always be open to questioning the status quo.

Basically, built-in checks should fail late, and refinements should fail early, and this difference is okay because built-in checks and refinements are actually very different.

It seems like the idea of trying multiple refinements probably came from the idea that we should get error messages from all the built-in checks that are violated, like .min(1).max(80).email().
I agree this makes sense for built-in checks. But note, built-in checks are not really refinements -- they don't chain together additional Zod nodes, change the output type, or use ZodEffects like refinements do, and they don't allow procedural code that could throw an error if any assumptions aren't met.

In most cases where a chain of Zod nodes is formed, parsing doesn't continue past a node that errored. Refinements are additional nodes so they should conform to this by default, to be least surprising. Built-in checks, on the other hand, are all applied by the same node, so it isn't surprising for them all to be tried. But if any built-in checks fail, parsing shouldn't continue past that node to a subsequent .pipe or .transform or .refine` or whatever. If people want it, there could be an option to opt in to successive refinements - but opt-in would be a more sensible default than opt-out.

[colinhacks]

I think the real answer here is to provide a mechanism for marking a refinement as "fatal". This will likely happen in Zod 4 but I don't have an RFC yet.

z.string().url({ fatal: true })
z.string().refine(val => val.length > 10, { fatal: true })

Relatedly, refinements will be stored "in-schema" in Zod 4, as opposed to the current compositional approach with ZodEffects. There will be a standard format for both built-in checks and user-defined checks, and they'll live alongside each other in ._def.checks.

Ideally there would be a reasonable, easily-understandable rule for which checks are considered "default fatal" and which aren't. But practically speaking, I doubt it will be so simple. I see the argument for things like .email() and .url() being fatal but .min() and .refine() being non-fatal. We'll probably have to make case-by-case judgement calls for these.

[jedwards1211]

.refine() being non-fatal

If there's a way we can disallow .refine predicates from returning val is NewType without { fatal: true } then that would be best since otherwise it violates the input type expected by the next Zod node in the chain. I guess at least we could make it not do the predicate extends (val, ...) => val is infer O logic without fatal: true.

[jedwards1211]

And if that's not possible, then maybe .refine could be fatal by default in Zod 4, and people who want it not to be would have to opt in?

[jedwards1211]

@colinhacks it might be nicer to have a method like .fatal() or .bail() or something that means stop refining if any of the previous refinements failed, so that we don't have to pass {fatal: true} to every one:

z.string().min(1).max(64).email().fatal().refine(...)

[hexwit]

Is there any way to make it stop on the first failure?

[JacobWeisenburger]

not that I know of, but perhaps someone else would know.

[hexwit]

However this kind of validation works as expected:

validate: zodResolver(
            z.object({
                email: z.string().email({message: "Email has invalid format"}).min(1, "This is a required field"),
            })
        ),

Chained validation, showed first appeared error. it is like something wrong with refine chaining.

[JacobWeisenburger]

Not sure what you are talking about, because this produces both errors.

const schema = z.object( {
    email: z.string().email( { message: "Email has invalid format" } ).min( 1, "This is a required field" ),
} )

const result = schema.safeParse( { email: '' } )
!result.success && console.log( result.error.issues )
// [
//     {
//         validation: "email",
//         code: "invalid_string",
//         message: "Email has invalid format",
//         path: [ "email" ]
//     }, {
//         code: "too_small",
//         minimum: 1,
//         type: "string",
//         inclusive: true,
//         exact: false,
//         message: "This is a required field",
//         path: [ "email" ]
//     }
// ]