yup.string().email() validate the email incorrectly

[easyhunn]

The validation for yup.string().email() allows an invalid email such as 2@344 to be marked as valid. Yup version 1.3.3

[esau-morais]

try using .matches instead, because they use the html standards and it is just assumes the basic cases

https://github.com/jquense/yup/blob/master/src/string.ts#L19-L21

also refer to the docs

[Kaique292]

The year is 2024, and the guys still haven't fixed email validation. Complicated..

[Kaique292]

You can use this RegEX too /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/

[jquense]

@Kaique292 It doesn't need fixing it's working as intended. Plz read the numerous longer explanations i've written over the years about this

[Kaique292]

@Kaique292 It doesn't need fixing it's working as intended. Plz read the numerous longer explanations i've written over the years about this

So, honestly I don't understand, if I need to use a RegEx for it to work, then it doesn't work, the most common email types are @. and yup.string().email() doesn't validate this correctly. Instead of validating correctly taking into account the most common use of email, and leaving any other type of email less common using regEx with test method

[jquense]

I'm not going to rehash it here, you can look through the many other places i've explained why this is the way it is, tl;dr there is no "correct" email regex, only ones that suit your needs better.

[xchwarze]

I agree with jquense's explanation, although I really wouldn't mind if some kind of workaround was integrated in the library.... I use Yup since 2017/2018 and I use it in all my projects (and I plan to keep using it) and really having to go project by project doing this workaround is a bit cumbersome...

[zackdotcomputer]

I think that there is "correct" and there is "useful," and in this case the usefulness of the library has been compromised in the sake of it being correct to an already loosely adhered-to spec.

The fact that the spec for email addresses allows emails like user@computer is somewhat irrelevant when developers are looking for something that will, in practice, provide validation that the email address being inputted to a form is likely going to actually work. The minor change of requiring a . in the hostname portion of the address would increase the usefulness of the library and, if one wants blessing from an org to do so, would bring the library in line with ICANN's recommendations for email addresses.