Problem
src/utils/validateEmail.ts gates the contact form (src/components/Contact/useContactForm.ts line 41) with a hand-written regex:
/^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|.(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/
The second alternative in the local part is |.(".+"), where the leading . is an unescaped any-character. That was clearly meant to be an escaped dot or a quoted-string form. As written it accepts things like x"anything"@example.com while the intended quoted-local-part syntax "a b"@example.com is not what it matches. The function also returns the match array or null rather than a boolean, which is why the call site has to use !validateEmail(email).
Why it matters
It is a small, self-contained correctness bug on the one input the contact form validates, and the regex is unreadable enough that nobody will spot the next bug in it either.
Suggested approach
- Replace the regex with something deliberately simple and documented, for example a single
@, a non-empty local part, and a dotted domain. Client-side email validation cannot prove deliverability, so its only job is to catch typos without rejecting valid addresses. Say that in a comment.
- Return a real
boolean.
- Consider deferring to the platform:
<input type="email"> plus input.checkValidity() is well specified and free. If you keep the helper, keep the two in agreement.
- Add unit tests once the harness lands: valid plain address, plus address (
a+b@example.com), subdomain, uppercase, missing @, missing TLD, leading and trailing whitespace.
Done when
validateEmail returns a boolean and its rule is one readable line plus a comment.
- The cases above are covered by tests.
Good first issue: one small file and one call site.
If you want to take this on, comment on the issue to claim it and it will be assigned. Please keep to a maximum of 2 open claims per person at a time so other contributors get a chance.
Problem
src/utils/validateEmail.tsgates the contact form (src/components/Contact/useContactForm.tsline 41) with a hand-written regex:The second alternative in the local part is
|.(".+"), where the leading.is an unescaped any-character. That was clearly meant to be an escaped dot or a quoted-string form. As written it accepts things likex"anything"@example.comwhile the intended quoted-local-part syntax"a b"@example.comis not what it matches. The function also returns the match array ornullrather than a boolean, which is why the call site has to use!validateEmail(email).Why it matters
It is a small, self-contained correctness bug on the one input the contact form validates, and the regex is unreadable enough that nobody will spot the next bug in it either.
Suggested approach
@, a non-empty local part, and a dotted domain. Client-side email validation cannot prove deliverability, so its only job is to catch typos without rejecting valid addresses. Say that in a comment.boolean.<input type="email">plusinput.checkValidity()is well specified and free. If you keep the helper, keep the two in agreement.a+b@example.com), subdomain, uppercase, missing@, missing TLD, leading and trailing whitespace.Done when
validateEmailreturns a boolean and its rule is one readable line plus a comment.Good first issue: one small file and one call site.
If you want to take this on, comment on the issue to claim it and it will be assigned. Please keep to a maximum of 2 open claims per person at a time so other contributors get a chance.