Little did I know that the start of my adventure with Esprima three years ago will result in something beyond my expectation. While the syntax tree format used by Esprima is not original (see SpiderMonkey Parser API), this de-facto format gains a lot of traction since it provokes a Cambrian explosion of composable JavaScript language tooling, everything from a code coverage tool, a style checker, a delta debugger, a syntax autocompleter, a complexity visualizer, and many more. Mind you, this AST format is far from perfect and hence why some of us at Shape Security are taking a journey to figure out a better format.
Throughout the development, Esprima is also being used as a playground for a rigorious workflow. For example, performance is always important and hence why a benchmark system was implemented early on. There were numerous optimized JavaScript tricks (fixed object shape, profile-guided code shuffling, object-in-a-set) which I discovered via a few interesting investigations. Esprima also enforces a hard threshold of certain metrics, such as cyclomatic complexity and test coverage. Speaking of tests, I consider Esprima’s test suite (~ 800 unit tests) as its crown jewel. It is not uncommon to hear that this collection of tests is being utilized to assist the development of another similar parser, whether it is written in JavaScript or other languages.
After being in the wild for a while, Esprima started to attract more contributions, not only in term of adding new features but also for troubleshooting defects, solving performance challenges, and other less glamorous tasks. The growth, 600 dependent packages and 3 millions/month download on npmjs, needs to be anticipated as well. This was why after talking to Dave Methvin some time ago, I felt confident that jQuery Foundation would be a good new umbrella for the project. And that was how the adoption was initiated and finally completed a few weeks ago.
At the same time, JavaScript continues to evolve. The next edition, ECMAScript 6 (will be called ECMAScript 2015 officially) has its specification frozen, with some JavaScript engines (SpiderMonkey, V8, Chakra, JavaScriptCore) already start to support a few selected features. This has been anticipated by creating the special harmony branch in early 2012. In fact, it has served as the basis of a transpiler called (now defunct) Harmonizr, back when writing a transpiler was not considered cool yet. Meanwhile, more folks (particularly Facebook engineers and some others) continue to enhance this branch. It is being used to drive Facebook JavaScript infrastructure (see JSTransform, Recast, Regenerator, JSX), among others for its ES6 adoption. Still, this harmony branch (despite some unofficial third-party releases) is considered experimental and it should not be used in production.
This brings us to the most recent 2.0 release. Among others, this release starts to include carefully selected ES6 features (e.g. arrow function, default parameter, method definition). This is to facilitate the migration of downstream language tools, per the original plan outlined several months ago in the mailing-list:
The new master, which bears the version 2.x, will start to introduce ECMAScript 6 features. We will do it peacemeal, taking features which are known to be more or less stabilized in the most recent draft spec. In a few cases, this is a matter of bringing in the existing implementation from the experimental harmony branch.
Thanks to the wonderful community, these three years have been fantastic. Let’s continue to build amazing tools!