Story of a contribution
As the EmailValidator library for PHP approaches the 100M downloads driven by the adopion from major PHP frameworks such as Symfony, Laravel or Drupal; near its 7th anniversary (version 1 was published the 19th of May of 2013, thanks git+github for this) I took two decisions.
First, to start version 3 with the objective to modernize the library (I want to improve the inner workings) while taking advantage of PHP 7 features and help the ecosystem move forward.
Second, to write this post about how I got into creating the library and became the author and sole mainteiner of a widely, depended upon (hopefully also used) open source library dedicated to the humble task of letting your application know if an email is valid. Which by the way is anything but trivial, as I learnt “the hard way” (r).
Join me in this retrospective into the dawn of modern PHP and the dwelings of a PHP developer, almost 8 years ago.
Back in the day when the Symfony PHP framework was gearing towards version 2 I got involved in a project using it in very early versions.
Most elements were quite unstable at that time. Composer was yet to be, so dependencies were handled in a plain text file. Forms were a beast to be tamed. But it was (or at least it felt to us) modern and a challenge.
As time went by I got involved in the community around the framework, assisting to framework specific conferences and even going into stage to deliver some talks.
Of course it was a matter of time to start contributing, which I did in several attempts and forms. First by creating my own libs for the framework and then by contributiting to the framework “core”.
Improve EmailValidator — Easy
I started gazing through the available issues to solve. At that time they (Symfony’s core team, albeit that concept came later) were using a label dubbed “easy” (or similar) and so I landed in issue #1581 Improve EmailValidator. As a summary, the reason was looking for alternatives to PHP’s built-in function “filter_var” which was (is?) very light in regards of email validation.
Where to start? First was transforming Dominic Sayers’s isemail “function” and adapt it to Symfony’s validation mechanics.
Next was understanding isemail function. This library used a complex RegEx (Regular Expression) to extract/validate email parts. You know what they say: if you have a problem to solve with a RegEx, then you have two problems.
It took almost no time to get the recommendation from the core mainteiners to use a Lexer/Parser to be able to work properly with an ABNF notation (IETF RFCs are written using Augmented Bakus-Naur form (ABNF) according to RFC5234). I was completely new to ABNF and Lexer/Parser. In fact, so far the approach to the task was to just port existing code by relying on the test suite.
A whole new world
I dug into lexing and parsing. I started actually reading the email address specifications RFCs, because for defining an email address (local part, domain mart, mx, etc) there are at least 5 RFCs (5321, 5322, 6530, 6531, 6532) to get your hands on to be as RFC compliant as possible. By the way, RFC Reader is a great tool for that if you ever have the opportunity to use it.
I also got curious about how RegEx engines worked (the lexer, the part that creates tokens from a string uses a RegEx to be able to tokenize) and read a book about it (Mastering Regular Expresions). Quite interesting in fact.
I learnt a lot. Because besides email validation I learnt about review processes and comments (from people you barely knew his/her github handle), how open source collaboration works, documenting changes as part of the code review, etc.
And after almost 16 months of work the EmailValidator libray was merged into Symfony 2 and has been part of the validation package ever since.
With the help of the core mainteiners the library became more stable and improved it’s range RFC compliance. Which paved the way to integrate it into Swiftmailer (PHP library for sending emails, used by Symfony until Symfony Mailer component was created).
And as the PHP ecosystem started to use Symfony components, was that the EmailValidator began its journey into becoming a building part of the PHP ecosystem.
Maintenance time!
However the journey was jsut starting. With authoring an open source library of moderate success you get the perk of maintaining it.
Beside solving bugs and adding improvements, for such an specific functionality I discovered that you also have to do some teaching, in the good sense. Because common sense would say that
this(example)@example.com
tellme~why@example.com
are not a valid email addresses. You guessed it, they are.
Because any printable ASCII character can be part of an email address. Or because email addresses can have comments (parenthesis)(!) . And by the way, according to RFC6530 Unicode (UTF-8) are also valid (say hello to josé@example.com).
Plenty of questions requesting (claiming to the heavens) why this or that email were valid arrived. It was at first a shock!
Patience and good manners always triumph and so I took every chance and question to re-validate my understanding of the RFCs before answering.
Beware future open source authors! Maintenance is part of the succes and by far the task that you would perform for the most time if your library has any level of adoption.
My breackable toy — a nice side effect
At some point I read the book Aprentship Patters by Dave Hoover & Adewale Oshineye, from which one the patterns is “Breackable toy”. This pattern is used for learning new languages and suggesets the creation of a program that you are familiar enough with the logic, so that if you want to learn a new language you would implement this same program time and time again focusing on the language and not in the logic.
EmailValidator became that and I used it for learning Java and then Scala (funny though, I did a contribution to Scala’s parser combinators package because of a single quote), along with their mechanisms for publishing libraries and software distribuition.
That’s it. 1 year of implementation, 6 years of maintenance (and counting!). I’m happy to have come across that easy issue and had the opportunity to lear tons of new things that otherwise might have gone unnoticed.
I hope you have enjoyed this short story on how the EmailValidator came to be and how it got adopted.
Happy validation!
