de72ce6ce7
* Properly guard for..in loops with Object#hasOwnProperty.
I noticed that babylon spends a lot of time in what we call *slow mode*
`for..in` when running in Node (on V8), and the reason for that is that
the version distributed on npm is build with *loose mode*, which turns
methods on the prototype into enumerable properties. Let's look at a
simplified example of the `State` class from `src/tokenizer/state.js`:
```js
class State {
constructor() { this.x = 1; }
clone() {
var state = new State();
for (var key in this) {
var val = this[key];
state[key] = val;
}
return state;
}
}
```
According to the specification the `State.prototype.clone` method is
non-enumerable. However when transpiling this with loose mode, we get
the following output:
```js
var State = (function() {
function State() { this.x = 1; }
State.prototype.clone = function clone() {
var state = new State();
for (var key in this) {
var val = this[key];
state[key] = val;
}
return state;
}
return State;
})();
```
So all of a sudden the `State.prototype.clone` method is enumerable.
This means that the `for..in` loop inside of that method enumerates
`x` and `clone` for `key`, whereas originally it was supposed to only
enumerate `x`. This in turn means that the shape of the result of a
call to `clone` will be different than the shape of a state that is
created via the `State` constructor. You can check this in `d8` using
the `--allow-natives-syntax` flag and this simple test driver:
```js
const s = new State;
%DebugPrint(s);
%DebugPrint(s.clone());
```
Using either the class version or the transpiled version we see:
```
$ out/Release/d8 --allow-natives-syntax state-original.js
0x2a9d7970d329 <State map = 0x2a9d40b0c751>
0x2a9d7970d3c1 <State map = 0x2a9d40b0c751>
$ out/Release/d8 --allow-natives-syntax state-loose.js
0x3729ee30d1b9 <State map = 0x3729af90c701>
0x3729ee30d251 <State map = 0x3729af90c7a1>
```
So as you can see, the transpiled version (using *loose mode*) produces
a different shape for the result of `clone`, whereas the original
version is fine. This pollutes all sites which use either a state
created from the `State` constructor or returned from the `clone`
method. The original one has only the `x` property in either case,
whereas in the transpiled version the result of `clone` has properties
`x` and `clone` on the instance.
To mitigate this effect, it's best to guard the `for..in` loops with
`Object.prototype.hasOwnProperty` calls, such that the actual body of
the loop only deals with own properties and not with properties from the
prototype chain. This change does exactly that for the two affected
`clone` functions.
In addition to the performance hit because of the unnecessary
polymorphism, there's also the performance hit because of the *slow
mode* `for..in` itself, which has to collect the properties from the
instance plus the prototype. Ideally the prototype properties shouldn't
be enumerable to avoid this whole set of problems. I see a couple of
possible solutions:
1. Distribute the original ES2015 version via npm.
2. Don't use loose mode, so that `Object.defineProperty` is used
instead, correctly passing `enumerable:false`.
3. Globally change loose mode in Babel to generate the correct and
fast `Object.defineProperty` instead.
I'd personally prefer a combination of 1. and 3. here, but I'm aware
that distributing the ES2015 code might not be an option yet. So the
mitigation of properly guarding the `for..in` here should already help.
But it'd be nice to have a discussion on using `Object.defineProperty`
in general, as I imagine that this could easily bite other applications
as well and this performance cliff is completely unobvious to
developers.
* Switch to Object.keys and Array.prototype.forEach.
Babylon is a JavaScript parser used in Babel.
- The latest ECMAScript version enabled by default (ES2017).
- Comment attachment.
- Support for JSX, Flow, Typescript.
- Support for experimental language proposals (accepting PRs for anything at least stage-0).
Credits
Heavily based on acorn and acorn-jsx, thanks to the awesome work of @RReverser and @marijnh.
API
babylon.parse(code, [options])
babylon.parseExpression(code, [options])
parse() parses the provided code as an entire ECMAScript program, while
parseExpression() tries to parse a single Expression with performance in
mind. When in doubt, use .parse().
Options
-
allowImportExportEverywhere: By default,
importandexportdeclarations can only appear at a program's top level. Setting this option totrueallows them anywhere where a statement is allowed. -
allowReturnOutsideFunction: By default, a return statement at the top level raises an error. Set this to
trueto accept such code. -
allowSuperOutsideMethod: TODO
-
sourceType: Indicate the mode the code should be parsed in. Can be either
"script"or"module". -
sourceFilename: Correlate output AST nodes with their source filename. Useful when generating code and source maps from the ASTs of multiple input files.
-
startLine: By default, the first line of code parsed is treated as line 1. You can provide a line number to alternatively start with. Useful for integration with other source tools.
-
plugins: Array containing the plugins that you want to enable.
-
strictMode: TODO
-
ranges: Adds a
rangesproperty to each node:[node.start, node.end] -
tokens: Adds all parsed tokens to a
tokensproperty on theFilenode
Output
Babylon generates AST according to Babel AST format. It is based on ESTree spec with the following deviations:
There is now an
estreeplugin which reverts these deviations
- Literal token is replaced with StringLiteral, NumericLiteral, BooleanLiteral, NullLiteral, RegExpLiteral
- Property token is replaced with ObjectProperty and ObjectMethod
- MethodDefinition is replaced with ClassMethod
- Program and BlockStatement contain additional
directivesfield with Directive and DirectiveLiteral - ClassMethod, ObjectProperty, and ObjectMethod value property's properties in FunctionExpression is coerced/brought into the main method node.
AST for JSX code is based on Facebook JSX AST with the addition of one node type:
JSXText
Semver
Babylon follows semver in most situations. The only thing to note is that some spec-compliancy bug fixes may be released under patch versions.
For example: We push a fix to early error on something like #107 - multiple default exports per file. That would be considered a bug fix even though it would cause a build to fail.
Example
require("babylon").parse("code", {
// parse in strict mode and allow module declarations
sourceType: "module",
plugins: [
// enable jsx and flow syntax
"jsx",
"flow"
]
});
Plugins
| Name | Code Example |
|---|---|
estree (repo) |
n/a |
jsx (repo) |
<a attr="b">{s}</a> |
flow (repo) |
var a: string = ""; |
typescript (repo) |
var a: string = ""; |
doExpressions |
var a = do { if (true) { 'hi'; } }; |
objectRestSpread (proposal) |
var a = { b, ...c }; |
decorators (Stage 1) and decorators2 (Stage 2 proposal) |
@a class A {} |
classProperties (proposal) |
class A { b = 1; } |
classPrivateProperties (proposal) |
class A { #b = 1; } |
classPrivateMethods (proposal) |
class A { #c() {} } |
exportExtensions (proposal 1), (proposal 2) |
Proposal 1: export v from "mod" Proposal 2: export * as ns from "mod" |
asyncGenerators (proposal) |
async function*() {}, for await (let a of b) {} |
functionBind (proposal) |
a::b, ::console.log |
functionSent |
function.sent |
dynamicImport (proposal) |
import('./guy').then(a) |
numericSeparator (proposal) |
1_000_000 |
optionalChaining (proposal) |
a?.b |
importMeta (proposal) |
import.meta.url |
bigInt (proposal) |
100n |
optionalCatchBinding (proposal) |
try {throw 0;} catch{do();} |
throwExpressions (proposal) |
() => throw new Error("") |
pipelineOperator (proposal) |
a |> b |
nullishCoalescingOperator (proposal) |
a ?? b |
FAQ
Will Babylon support a plugin system?
Previous issues: babel/babel#1351, #500.
We currently aren't willing to commit to supporting the API for plugins or the resulting ecosystem (there is already enough work maintaining Babel's own plugin system). It's not clear how to make that API effective, and it would limit out ability to refactor and optimize the codebase.
Our current recommendation for those that want to create their own custom syntax is for users to fork Babylon.
To consume your custom parser, you can add to your .babelrc via its npm package name or require it if using JavaScript,
{
"parserOpts": {
"parser": "custom-fork-of-babylon-on-npm-here"
}
}