👋 Hi there! 👋

And thank you for opening your first issue! We will get back to you shortly. 🏃 💨

@RaviSadam See the package's notes: https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/assert/is-email-address#notes. The current behavior is intentional.

@kgryte Yaa. But the regex using to check the email address is /@/ ,which only checks if the "@" symbol is present in the string. It doesn’t validate the full email format like characters before/after the "@" or the domain name.
Please look into attached code and output.

const isEmail=require('@stdlib/assert/is-email-address');
const email_address=[["[email protected]",true],["abc",false],["@",false],["abc@com",false]]
for(const arr of email_address){
    const actual=isEmail(arr[0]);
    console.log(`email address: ${arr[0]},actual: ${actual}, expected:${arr[1]}`)
}

Wrong Regex: file

As I stated, read the notes and the associated linked reference. From there, feel free to read RFC 2822: https://datatracker.ietf.org/doc/html/rfc2822. Coming up with a robust regexp to validate an e-mail address is a fool's errand. Most e-mail validators are broken. According to the RFC, abc@com is valid, etc.

@kgryte
According to the RFC, an email address like abc@com is considered valid. However, I don't believe the @ symbol is inherently valid according to the RFC. While creating a robust regular expression to fully validate an email address is a challenging task, we can still write a regular expression that validates common email patterns at least.

Here few sample tests where the is-email-address is failing

const isEmail=require('@stdlib/assert/is-email-address');
const email_address=[["@gmail.com",false],["abc@",false],["@",false],["abc@gmail@com",false]]
for(const arr of email_address){
    const actual=isEmail(arr[0]);
    console.log(`email address: ${arr[0]},actual: ${actual}, expected:${arr[1]}`)
}

output

email address: @gmail.com,actual: true, expected:false
email address: abc@,actual: true, expected:false
email address: @,actual: true, expected:false
email address: abc@gmail@com,actual: true, expected:false

If you think you can succeed where all others have failed and can develop a regular expression that perfectly satisfies the RFC, by all means, feel free to submit a PR.

We spent a lot of time looking into this previously and came away with the belief that almost all validation approaches lead to erroneous false negatives. Happy to be proven wrong. However, note that we will expect full RFC 2822 compliance and any associated changes should be accompanied by a comprehensive associated test suite.

I completely understand the challenges associated with achieving full RFC 2822 compliance, particularly given the complexity of the specification. I truly appreciate the effort your team has already put into exploring this issue. I was able to come up with a regex that perfectly aligns with common email patterns, and I’ll build on this to ensure compliance with the full specification. I’ll also ensure that any changes are accompanied by a comprehensive test suite to validate compliance and account for potential edge cases, minimizing erroneous false negatives.
If you’re okay with this approach, I’d be happy to open a PR for this issue and begin working collaboratively toward a solution.
Thank you😊

@RaviSadam Based on your response, please do not submit a PR for a regexp generated by an LLM. It is nearly 100% guaranteed to be wrong.