Need a way to overwrite the email validate logic.

[jswxwxf]

Need a way to overwrite the build-in regexp logic that angularjs used to validate the email.
It should be customizable.

[lord2800]

ng-pattern="/my-regex/"?

[jswxwxf]

Thanks for answering:)
I know ng-pattern, but it's adding regex check on the email, not replacing the build-in one.

[caitp]

I think you should stop trying to replace the email validation, because this is what email validation is on the web. Does it suck? Well sure, email sucks, but it's what we've got. This is how it works in your browser as well, or at least will be shortly once the last PR for email validation lands.

If you want to enforce that emails are from a specific TLD or something, or even just ensure that they HAVE a TLD, just add a pattern, really. This same line of thinking has been covered at the WHATWG

[jswxwxf]

Yes, I want to use angularjs's buildin email validator also, but the requirement is always from customers...

[Narretz]

I agree that something should be done about this, since it will pop up over and over again. Would it conflict with HTML5 constraint validation if the regex angular uses was configurable? Once email & input are merged, it'll also be possible to overwrite the validator. We could mention that or the pattern way in the docs.

[caitp]

the email validator should really match what browsers do --- however we could make it possible to register "extra" validation logic to it.

[rolfyone]

are there examples of 'valid' emails that currently fail validation that lead to this being needed?

is this just the something@some kind of scenario mentioned in #7979 or are there others too that are of specific concern?

[jimmywarting]

one invalid email that passes in angular (but not in the browser) is something@some:aaaa where the port can only be a number

[caitp]

you can't actually include a port number in email hosts, but if we're accepting that then that's a bug to fix in angular. You can extend validation with ng-pattern, however.