Once upon a time, an unsuspecting Mozilla engineer created an API in Firefox that exposed the SpiderMonkey engine's JavaScript parser as a JavaScript API. Said engineer documented the format it produced, and this format caught on as a lingua franca for tools that manipulate JavaScript source code.
Meanwhile JavaScript is evolving, notably with the upcoming release of ES2015. This site will serve as a community standard for people involved in building and using these tools to help evolve this format to keep up with the evolution of the JavaScript language.
We've started the process of bringing together various communities using this format to move it forward into the ES2015 era and beyond. Feel free to join us! We'll be discussing in the issue tracker and in #esprima
on Freenode.
The spec uses a custom syntax to describe its structures. For example, at the
time of writing, 'es2015.md' contained a description of Program
as seen below
extend interface Program {
sourceType: "script" | "module";
body: [ Statement | ModuleDeclaration ];
}
- Dave Herman (Mozilla)
- Ingvar Stepanyan (Acorn)
- Nicholas C. Zakas (ESLint)
- Mike Sherov, Ariya Hidayat (Esprima)
- Michael Ficarra (@michaelficarra)
- Henry Zhu, Logan Smyth, Daniel Tschinder (Babel)
Suggested additions and modifications must follow these guidelines:
- Backwards compatible: Non-additive modifications to existing constructs will not be considered unless immense support is in favor of such changes. (eg. #65)
- Contextless: Nodes should not retain any information about their parent. ie. a
FunctionExpression
should not be aware of if it's a concise method. (eg. #5) - Unique: Information should not be duplicated. ie. a
kind
property should not be present onLiteral
if the type can be discerned from thevalue
. (eg. #61) - Extensible: New nodes should be specced to easily allow future spec additions. This means expanding the coverage of node types. ie.
MetaProperty
overNewTarget
to cover future meta properties. (eg. #32)