vlad 6f123ff03e 18.07 | před 6 roky | |
---|---|---|
.. | ||
bin | před 6 roky | |
lib | před 6 roky | |
CHANGELOG.md | před 6 roky | |
LICENSE | před 6 roky | |
README.md | před 6 roky | |
package.json | před 6 roky |
Babylon is a JavaScript parser used in Babel.
Heavily based on acorn and acorn-jsx, thanks to the awesome work of @RReverser and @marijnh.
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()
.
allowImportExportEverywhere: By default, import
and export
declarations can only appear at a program's top level. Setting this
option to true
allows them anywhere where a statement is allowed.
allowAwaitOutsideFunction: By default, await
use is not allowed
outside of an async function. Set this to true
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: 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 ES6 import
or export
statements. Files with ES6 import
s and export
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: TODO
ranges: Adds a ranges
property to each node: [node.start, node.end]
tokens: Adds all parsed tokens to a tokens
property on the File
node
Babylon 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
directives
field with Directive and DirectiveLiteralAST for JSX code is based on Facebook JSX AST.
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.
require("babylon").parse("code", {
// parse in strict mode and allow module declarations
sourceType: "module",
plugins: [
// enable jsx and flow syntax
"jsx",
"flow"
]
});
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 |
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"
}
}