@babel/parser
The Babel parser (previously 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
babelParser.parse(code, [options])
babelParser.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,
import
andexport
declarations can only appear at a program's top level. Setting this option totrue
allows them anywhere where a statement is allowed.allowAwaitOutsideFunction: By default,
await
use is not allowed outside of an async function. Set this totrue
to accept such code.allowReturnOutsideFunction: By default, a return statement at the top level raises an error. Set this to
true
to accept such code.allowSuperOutsideMethod: By default,
super
use is not allowed outside of class and object methods. Set this totrue
to accept such code.sourceType: Indicate the mode the code should be parsed in. Can be one of
"script"
,"module"
, or"unambiguous"
. Defaults to"script"
."unambiguous"
will make @babel/parser attempt to guess, based on the presence of ES6import
orexport
statements. Files with ES6import
s andexport
s 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: By default, ECMAScript code is parsed as strict only if a
"use strict";
directive is present or if the parsed file is an ECMAScript module. Set this option totrue
to always parse files in strict mode.ranges: Adds a
ranges
property to each node:[node.start, node.end]
tokens: Adds all parsed tokens to a
tokens
property on theFile
node
Output
The Babel parser generates AST according to Babel AST format. It is based on ESTree spec with the following deviations:
There is now an
estree
plugin 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
directives
field 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
The Babel Parser 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("@babel/parser").parse("code", {
// parse in strict mode and allow module declarations
sourceType: "module",
plugins: [
// enable jsx and flow syntax
"jsx",
"flow"
]
});
Plugins
Miscellaneous
Name | Code Example |
---|---|
estree (repo) | n/a |
Language extensions
Name | Code Example |
---|---|
flow (repo) | var a: string = ""; |
flowComments (docs) | /*:: type Foo = {...}; */ |
jsx (repo) | <a attr="b">{s}</a> |
typescript (repo) | var a: string = ""; |
ECMAScript proposals
Name | Code Example |
---|---|
asyncGenerators (proposal) | async function*() {} , for await (let a of b) {} |
bigInt (proposal) | 100n |
classProperties (proposal) | class A { b = 1; } |
classPrivateProperties (proposal) | class A { #b = 1; } |
classPrivateMethods (proposal) | class A { #c() {} } |
decorators (proposal)decorators-legacy | @a class A {} |
doExpressions (proposal) | var a = do { if (true) { 'hi'; } }; |
dynamicImport (proposal) | import('./guy').then(a) |
exportDefaultFrom (proposal) | export v from "mod" |
exportNamespaceFrom (proposal) | export * as ns from "mod" |
functionBind (proposal) | a::b , ::console.log |
functionSent | function.sent |
importMeta (proposal) | import.meta.url |
logicalAssignment (proposal) | a &&= b |
nullishCoalescingOperator (proposal) | a ?? b |
numericSeparator (proposal) | 1_000_000 |
objectRestSpread (proposal) | var a = { b, ...c }; |
optionalCatchBinding (proposal) | try {throw 0;} catch{do();} |
optionalChaining (proposal) | a?.b |
partialApplication (proposal) | f(?, a) |
pipelineOperator (proposal) | a |> b |
throwExpressions (proposal) | () => throw new Error("") |
Plugins options
NOTE: When a plugin is specified multiple times, only the first options are considered.
decorators
:decoratorsBeforeExport
(boolean
)// decoratorsBeforeExport: true @dec export class C {} // decoratorsBeforeExport: false export @dec class C {}
pipelineOperator
:proposal
(required, accepted values:minimal
,smart
) There are different proposals for the pipeline operator. This option allows to choose which one to use. See What's Happening With the Pipeline (|>) Proposal? for more information.
flow
:all
(boolean
, default:false
) Some code has different meaning in Flow and in vanilla JavaScript. For example,foo<T>(x)
is parsed as a call expression with a type argument in Flow, but as a comparison (foo < T > x
) accordingly to the ECMAScript specification. By default,babel-parser
parses those ambiguous constructs as Flow types only if the file starts with a// @flow
pragma. Set this option totrue
to always parse files as if// @flow
was specified.
FAQ
Will the Babel parser 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 the parser.
To consume your custom parser, you can add a plugin to your options to call the parser via its npm package name or require it if using JavaScript,
const parse = require("custom-fork-of-babel-parser-on-npm-here");
module.exports = {
plugins: [{
parserOverride(code, opts) {
return parse(code, opts);
},
}]
}