* Add all option to babel-plugin-syntax-flow The Flow parser has some conditional logic based on whether types should be parsed or not, which is based on either (a) the @flow pragma in the docblock of the file of (b) the `all` configuration, provided via command line or .flowconfig. This commit adds the ability to provide the `all` configuration to Babel as well, via the syntax-flow plugin. This should be set to `true` if the project uses all=true. * Parse @flow pragma The Flow parser has some conditional logic based on whether types should be parsed or not, which is based on either (a) the @flow pragma in the docblock of the file of (b) the `all` configuration, provided via command line or .flowconfig. This commit parses the @flow (or @noflow) pragma from the first comment in the source file. Directives are allowed to appear before the comment. * WIP: add tests for explicit type arguments This commit includes tests which have unexpected output, but will change to the expected output as later commits add parsing support for various features. * Parse type arguments in new expressions * Parse type arguments in call expressions * Parse optional call expressions with explicit type args * Add explicit type arguments to babel-types Flow calls these typeArguments instead of typeParameters, which clearly separates formal/actual parameters, and mirrors the existing arguments key. The existing definitions to support TypeScript also included Flow's TypeParameterInstantiation node type, which I've moved to the the new field. * Add support for explicit type arguments to babel-generator * Add test for explicit type args to transform-flow-strip-types plugin * Oops. Forgot to regenerate the babel-types README. * Fix Flow parser shouldParseTypes() function I was looking at `options.all`, but the correct property ws `options.flowAll`. Oops! * Remove typeapp_call from whitelist of expected failures Now that Babylon parses this syntax extension, we can remove the typeapp_call tests from the list of expected differences. Note that I am using the `flowAll` option, mirroring the behavior of the Flow tests, which assume types without requiring the `@flow` pragma. * Use Babylon plugin options instead of parser options * Parse optional call expressions type arguments unambiguously
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. -
allowAwaitOutsideFunction: By default,
awaituse is not allowed outside of an async function. Set this totrueto accept such code. -
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 one of
"script","module", or"unambiguous". Defaults to"script"."unambiguous"will make Babylon attempt to guess, based on the presence of ES6importorexportstatements. Files with ES6imports andexports are considered"module"and are otherwise"script". -
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.
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 = ""; |
flowComments (docs) |
/*:: type Foo = {...}; */ |
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() {} } |
exportDefaultFrom (proposal) |
export v from "mod" |
exportNamespaceFrom (proposal) |
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: #1351, #6694.
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 our 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"
}
}