Replies: 2 comments
-
If you agree I would love to look into it and even make a PR |
Beta Was this translation helpful? Give feedback.
0 replies
-
I love the idea from a DX perspective, but admittedly it is a bit non-standard. I'm not aware of other validators with a functionality like this. Would love to hear some more opinions about it. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In the code we had a property annotated with isISO8601 validator. It somehow has no issue but it can lead to confusion in conjunction with class transformer.
When receiving something like '2020-12-04T00:00:00Z' and using typeorm to apply it to a date we ran into the error message "$property must be a valid ISO 8601 date string". We have been very confused cause we saw its a valid ISO date string but it always said it isnt.
Reason was that the class-transformer first translated the string into a date object. Then the class-validator exits early cause its not a string and outputs the error.
While there is nothing wrong its easy to miss out the subtle difference between @isdate and @isDateString.
I would propose adjusting the error message of the class-validator in this case. If the input is detected to be a date object, the error message could add a hint for the developer "the input is a date, did you mean @isdate()?".
Whats your thought on it? It fooled two experienced devs for an hour or more.
Beta Was this translation helpful? Give feedback.
All reactions