If you’re like me, you probably use a lot of open source tools every day without thinking about how they got started. Few projects share the “why” of their creation: the actual problem they were trying to solve and when they first came across that problem. You can, of course, benefit from open source projects without understanding their origin story, but I always find it interesting to hear about how it all started.
I recently realized that I’d never shared the origin story of ESLint. I’ve shared some of the decisions I made along the way in previous posts but never the initial domino that fell and led to ESLint’s creation. As you will see, ESLint wasn’t created through some divine intervention or stroke of insight, but rather through a series of events that eventually built up to ESLint’s creation.
I was still fairly new at Box when a teammate was working on a strange bug. A client had reported problems using the web application in Internet Explorer 7 (we were probably one of the last companies supporting IE7 at that point). A developer had apparently used the native
XMLHttpRequest object in IE7 was really just a wrapper around the ActiveX object, it was blocked as well.
The solution was easy enough, just make sure everyone knows to use the in-house Ajax wrapper instead of the native
In my experience, using regular expressions on source code was never a good idea. I wished that there was a better way to do checks like this one during the build. I figured that someone must have already solved this problem and so I started looking for solutions.
Could it be JSHint?
The first thing I did was email the maintainer of JSHint at that time, Anton Kovalyov. I had remembered reading a blog post that said JSHint was planning to support plugins but couldn’t find any information about that feature being implemented. From past experience contributing to JSHint and from modifying JSLint for a project at Yahoo, I knew JSHint hadn’t initially been setup to support plugins, and without formal support there wouldn’t be an easy way to modify JSHint to do what I wanted.
Anton informed me that the plugin proposal had stalled and didn’t look like it would be implemented. I was disappointed, as this seemed like the most direct path to solving the problem. I thanked him and asked him to please not be offended if I create a linter that did what I needed. I wanted to support JSHint, but I felt like this was a problem that needed to be solved with JSHint or without it.
As Ariya continued talking and giving examples of the types of problems an AST can solve, the idea for a new tool formed in my head. It made sense to me that there should be one tool that could perform all of the evaluations Ariya mentioned. After all, they are all just using the AST for different purposes. Why not have one AST they all can use?
(I feel it’s important to point out that I was not the only one looking to create an AST-based linter at the time. JSCS was also under development at around the same time, and current ESLint maintainer Ilya Volodin was working on his own project before discovering ESLint. If I had not come up with something like ESLint then someone else undoubtedly would have. All of the pieces were already out there thanks to Ariya and Yusuke, someone just had to put them together in a useful way.)