Feature Request: Custom error message for primitive type errors
See original GitHub issueYup allows for defining an error message for failed type checks via a typeError(message: string)
operator. Doesn’t seem like there’s anything like this in Zod. I’d rather have custom humanized error messages than an unchangeable: Expected number, received nan
.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:10
- Comments:7 (2 by maintainers)
Top Results From Across the Web
Feature Request: Custom error message for primitive type errors
Feature Request : Custom error message for primitive type errors ... Yup allows for defining an error message for failed type checks via...
Read more >A Definitive Guide to Handling Errors in JavaScript - Kinsta
Creating Custom Error Types However, throwing a primitive data type doesn't provide details about the error, such as its type, name, or the ......
Read more >"This value should be of the correct primitive type" error with ...
"This value should be of the correct primitive type" error with working file field in custom entity after upgrade to 8.8.0.
Read more >ASP.NET Core 5 -a way to check primitive datatype or change ...
IsValid in every endpoint. But with this feature, I would want to change error message for simple primitive types as integer etc.. -...
Read more >Suggestion: The `object` primitive type · Issue #1809 - GitHub
mcmath commented on Jan 30, 2017 ... @trusktr All values other than null and undefined are assignable to the Object type; a function...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I have just switched from Yup to Zod, because type inferring is better and it works better with react-hook-forms. I have a problem with this, too. I’m working with Zod 2 and there seems to be no way of handling errors like this.
I have a schema like this:
And there’s no way (or I couldn’t find any) to customize messages for type errors or messages if z.object() is missing.
This is my current work around
but I think my prefered pattern would be to either assume all types are optional unless marked as required (and allow custom message in that method) or to add a optional message to the constructor