fromError not returning same format as fromZodError

[grmkris]

const parsedObject = mySchema.safeParse(objToBeParsed);

if (!parsedObject.success) {
      const error = fromError(parsedObject.error);
      console.log(error.toString());
      throw new Error(error.toString());
    }

i'd expect the message to be HMR as with fromZodError.. but for some reason it returns the "plain" zod error

[thanoskrg]

Hi @grmkris 👋

I'm afraid I cannot understand what's the problem from the snippet above. Is it possible to provide more details about:

1. How does mySchema look like?
2. What is the "expected" behaviour according to fromZodError?
3. What does "HMR" mean in the context of this issue?

[grmkris]

hey sorry for incomplete issue.. let me expand below:

let's say the schema is:

const mySchema = z.object({
   a:  z.string(),
   b: z.string(),
   c: z.string()
})

when if I parse:

const toBeParsed = { 
   b: "qwew",
   c: "qqq"
}

const parsed = mySchema.safeParse(toBeParsed)
const error = fromError(parsed.error);

i'd expect the error object to be human readable (HMR)... but in fact is not.. it is the same object as zod returns with the array of errors found during parsing)

[grmkris]

hmmm tried to make simple replication here but it works OK https://stackblitz.com/edit/typescript-9rqdwj?file=schemas%2FschemaWithDefaultType.ts

[grmkris]

hey so i "found" the problem.. i have a package with some zod schema definitions.. these schemas are then imported in different packages and if i use the schema and parse it, then zod-validation-error doesn't convert it properly to the human readable, but just returns the array of issues

all my packages have the same versions of zod and zod-validation-error really weird why this happens.. i'll try to make a repo with full replication sometime in the following days, but hopefully I explained this in good enough way to

[jmike]

So this happens because you have multiple versions on zod in your project. Therefore, the instanceof check (as part of https://github.com/causaly/zod-validation-error/blob/b7c5af10fbedce76073af23a102bea359e383352/lib/toValidationError.ts#L9) fails because it's checking for a different prototype than the one you are using.

Although the classes seemingly have the same names, nodejs considers them an entirely different thing because they are different modules. This is not wrong. This is the way.

We could address the problem on our side by checking for err.name === 'ZodError' instead of err instanceof ZodError as zod sets a name prop (see https://github.com/colinhacks/zod/blob/110b8211f991b3e060ab2da4fec7b63d600439ad/src/ZodError.ts#L214).

However, such a change may introduce unwanted side-effects, i.e. when an error that is NOT a true ZodError instance but has the name ZodError. What are the chances? Slim, I would say, but still.

To be clear, this is NOT a issue of zod-validation-error. This is something you are doing wrong. However, given that there will be more people like you, we can consider the alternative.

@thanoskrg @nikoskalogridis what say you?

[grmkris]

hey the thing is that I am really careful with my zod versions in the monorep and all are the same version.. but are not pined to the latest, but rather with the ^ character

but maybe some downstream library might be using the old version and pnpm gets confused? but i don't think so, this is the first time i am encountering this issue on previous versions things were working fine, we can stay on those for time being, but i really like being on latest versions with my dependencies

will do some more expirimentation over the weekend and come back to you

[Phil-Barber]

Hey, @grmkris I battled with the same issue today. npm list zod is your friend - hope that helps!

[jmike]

@grmkris please try the latest zod-validation-error@3.3.0 version which relies on heuristics to match on ZodError instead of using instanceof. This should address the issue you are facing.