zod-validation-error: TypeError: Cannot read properties of undefined (reading 'slice') at fromZodError

I didn’t even see toValidationError, likely given the fact that it’s not on the npm page, or noted anywhere in the documentation

The toValidationError has been added to the docs for a while now. https://github.com/causaly/zod-validation-error?tab=readme-ov-file#tovalidationerror

Point taken that we need to do a better job describing the method.

Sidebar, any particular reason for toValidationError being a standalone function, rather than a static based method in the ValidationError class?

I am strongly opinionated here against OOP. I personally see no benefit of having it as a static method as part of ValidationError. Thanks for the suggestion though.

Given the number of people that seem to be facing an issue with .slice exception when a non-ZodError instance is passed to fromZodError, we are considering a few options to go about this.

Before we proceed though, I’d like to ask how come you don’t use the more relaxed helper which is toValidationError, and internally checks whether it should call fromZodError or construct a new ValidationError itself.

Honestly? I didn’t even see toValidationError, likely given the fact that it’s not on the npm page, or noted anywhere in the documentation. This does 100% solve the issue I have, however, the lack of any real documentation indicating that this method should be used over the fromZodError, or that it even exists. I would almost suggest the removal of fromZodError completely and instead recommend that everything go through toValidationError, but you guys have fromZodIssue, which is helpful as well, and not used in toValidationError at all.

If it were me, I’d remove all the from* functions (I realize this is a breaking change and therefore wouldn’t just happen in the next release) and instead move to a singular toValidationError which keeps the current logic, while also adding in logic to convert ZodIssues.

Sidebar, any particular reason for toValidationError being a standalone function, rather than a static based method in the ValidationError class? Perhaps this is my OOP bias showing, but it seems like it belongs there…

Oh, I absolutely feel like it is fair to say that it is in the user consumer to make sure they are using this package correctly and not passing in things they shouldn’t, I simply mean that by allowing this function to error when trying to call slice on undefined, as it does currently, gives off the impression that it is a bug, as based off the documentation I would expect a TypeError telling me that I passed an invalid argument, rather than the current behavior. It also seems somewhat against the original intention of this package, which was making it easier to use the error details returned by Zod. Seems a little counterproductive to use the current error as a means of saying you’ve passed the wrong value, no?

Regardless, I’d be interested in what others have to say. I don’t think it’s a huge deal either way, given it is rather easy to validate the error is a ZodError or not before hand.

They need to validate if it’s a ZodError themselves

@unRealGamer28 I understand your concern, although your test script above does only one thing, which is an object parsing using a zod schema. But what if in a real-world scenario your function did many things? Like http requests, IO operations plus zod schema parsing. Then you might end up with all sorts of different error instances.

So the point I’m trying to make is that it is almost inevitable to do a check against the instance of the error you are getting in the catch block. But there might be another discussion here, whether we could entertain the idea of adding an extra helper in the library, something like isZodError.

cc @jmike @nikoskalogridis what are your thoughts on this?