Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/pvdz/escaya
A blazing fast 100% spec compliant, self-hosted javascript parser written in Typescript
https://github.com/pvdz/escaya
Last synced: about 1 hour ago
JSON representation
A blazing fast 100% spec compliant, self-hosted javascript parser written in Typescript
- Host: GitHub
- URL: https://github.com/pvdz/escaya
- Owner: pvdz
- License: isc
- Created: 2020-06-24T06:41:42.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2020-06-24T06:53:08.000Z (over 4 years ago)
- Last Synced: 2024-12-10T14:53:28.830Z (3 days ago)
- Homepage:
- Size: 266 KB
- Stars: 0
- Watchers: 2
- Forks: 4
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE.md
Awesome Lists containing this project
- awesome-blazingly-fast - escaya - A blazing fast 100% spec compliant, self-hosted javascript parser written in Typescript (TypeScript)
README
Escaya
An 100% spec compliant, self-hosted javascript parser written in Typescript.
**Work in progress**
Still to early to release the source file to public, but a demo can be found [here](https://escaya.github.io/escaya/).
## Features
* Conforms to the standard ECMAScript® 2021 (ECMA-262 11th Edition) language specification
* Support for additional ECMAScript features for Web Browsers
* Optionally track syntactic node locations
* Emits an ECMAScript® 2021 compatible abstract syntax tree
* Error recovery mode with incremental parsing support
* JSON friendly
* No backtracking
* Low memory usage
* Optimized for use on handheld devices such as a mobile phone or tablet
* Very well tested (~15 000 unit tests with full code coverage)
* Lightweight - ~84 KB minified
## API
Escaya generates it's own `AST` that is close to the [ECMAScript® 2021 specs](https://tc39.es/ecma262/index.html), and can be used to perform [syntactic analysis](https://en.wikipedia.org/wiki/Parsing) (parsing) of a JavaScript program, and with `ES2015` and later a JavaScript program can be either [a script or a module](https://tc39.github.io/ecma262/index.html#sec-ecmascript-language-scripts-and-modules).
This is the available options:
```js
{
// Enable stage 3 support (ESNext)
next?: boolean;
// Disable web compatibility
disableWebCompat?: boolean;
// Enable line/column location information start and end offsets to each node
loc?: boolean;
// Allow return in the global scope
globalReturn?: boolean;
// Enable implied strict mode
impliedStrict?: boolean;
// Adds a source attribute in every node’s loc object when the locations option is `true`
source?: string;
// Enable parsing in module goal in error recovery mode
module?: boolean;
}
```
Example usage:
```ts
import { parseScript, parseModule, parse } from './escaya';
parseScript('({x: [y] = 0} = 1)');
parseModule('({x: [y] = 0} = 1)', { impliedStrict: true });
```
## Error recovery
When Escaya parser is given an input that does not represent a valid JavaScript program, it throws an exception. If parsing in
recovery mode, the parser will continue parsing and produce a syntax tree.
However, Escaya will continue to do a full parse for every keystroke. To avoid this you can enable incremental parsing. This is best demonstrated with an example.
```ts
import { recovery, update } from './escaya';
const rootNode = recovery('(foo);', 'filename.js', { module: true });
const ast = update(rootNode, '=> bar;', 'filename.js', { span: { start: 6, length: 0 }, newLength: 7 })
```
Now when incremental parsing have been enabled, Escaya will reuse nodes from the old tree if possible.
### Options
The options for the recovery mode are about the same as for `parseScript` and `parseModule` except you have to enable `{module: true}` if parsing in module goal.
No options can be set during an incremental update because it's only possible to reuse a node if it was parsed in the same context that parser are currently in.
### AST
One of the design goals for Escaya has been that the AST shouldn't change. It should be the same either you are parsing in `normal mode` or `recovery mode`.But there are a couple of exceptions. In `recovery mode` you are creating a `RootNode` instead of either a `Module` or `Script`, and this `RootNode` has additional information such as diagnostics, context masks and mutal parser flags that you *carry over* from the recovery mode to the incremental parsing and let you continue to parse in the same context that you are currently in unless you set a strict directive on the `RootNode`.
If you do this, Escaya will parse in strict mode and you will not be able to recover any nodes from the old tree if you were first parsing in *sloppy mode*, because
it's only possible to reuse a node if it was parsed in the same context that the parser are currently in.
## Escaya AST
The abstract syntax tree (AST) used by `Escaya` represents the structure of an ECMAScript program as a tree and conforms to the [ECMAScript® 2021 specification](https://tc39.es/ecma262/index.html). The AST have been designed for performance, and it nearly eliminates the chance of accidentally creating an AST that does not represent an ECMAScript program and it consumes less bytes than the AST produced by `ESTree` and `Babel`.
The `Escaya AST` doesn't try to follow the SpiderMonkey-compatible standard that `ESTree` strictly follows, and it distinguish `Identifier` from `IdentifierPattern` and makes it easier to calculate the free variables of a program.
## CLI
The CLI is still a TODO, but will parse Escaya in recovery mode and use the diagnostic messages to create an nice output so that you are always informed of invalid syntax and you can correct this.