https://github.com/TheLarkInn/js-parser-discussions
Discussions & Collaboration on a Unified/Base set of parser features for JavaScript
https://github.com/TheLarkInn/js-parser-discussions
Last synced: 2 months ago
JSON representation
Discussions & Collaboration on a Unified/Base set of parser features for JavaScript
- Host: GitHub
- URL: https://github.com/TheLarkInn/js-parser-discussions
- Owner: TheLarkInn
- Created: 2016-09-13T19:32:58.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2016-10-10T20:36:33.000Z (over 8 years ago)
- Last Synced: 2024-05-02T01:07:56.073Z (about 1 year ago)
- Size: 12.7 KB
- Stars: 41
- Watchers: 11
- Forks: 1
- Open Issues: 9
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# js-parser-discussions
Discussions & Collaboration on a set of parser features for JavaScript for interoperability.
## Disclaimer
This is a blameless medium. Focusing on a specific toolings shortcomings or bias or personal agendas, will not help accomplish the following goals. Therefore I urge that anyone involved uses an unbiased inspection of these tools to help identify ways to create an unopinionated, and extensible foundation.
## Synopsis
Currently there are a variety of JavaScript parsers that are available. Each of these parsers have specific purposes. These parsers include (but is not limited to):
- Family of [ESTree](https://github.com/estree/estree):
- [SpiderMonkey parser](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API)
- [Esprima](https://github.com/jquery/esprima)
- [Acorn](https://github.com/ternjs/acorn)
- [Espree](https://github.com/eslint/espree)
- [Babylon](https://github.com/babel/babylon)
- [Shift](https://github.com/shapesecurity/shift-parser-js)
- [UglifyJS](https://github.com/mishoo/UglifyJS/) (no dependant parser)
- [UglifyJS2 parser](https://github.com/mishoo/UglifyJS2)
- [Typescript parser](https://github.com/microsoft/typescript)
- [Traceur parser](https://github.com/google/traceur-compiler)
- [Flow parser](https://github.com/facebook/flow) (ml based)
Each of these parsers have specific feature set. For this synopsis, the reasonings behind those featuresets are irrelevant, however it is noteworthy to mention that often specific parsers are companions to specific frameworks, libraries, toolings, etc.
### Features?
- Esprima
- Acorn
- Babylon
- Uglify
## Current Challenges
Currently, frameworks, libraries, tools, optimizers, bundlers, coverage mappers, source-mappers (?), instrumenters, testing utilities, etc. have to make the choice to use 1 of the following parsers.
This causes many issues for interoperability:
- istanbul/coverage + transpiled libraries
- webpack + acorn + limited type support
- program flow based optimizations have to be implemented differently for every parser
## Naive Proposal/Discussion
What if we think of these different parsers as simply a set of features for _a single_ base parser? This could unify tools, parser _consumers_ and promote interoperability. A rich and configurable feature/plugin system, then allows for multi-framework support, and extensibility. (Experimental use of ES features, etc.)
```
parse
|-- event delegation
|-- syntax flagging
|-- custom estrees(?)/AST's
|-- typed language support
|-- (?)
```
## Lessons Learned from:
### Acorn
- Plugin system is hard, complex. Where can we learn from this?
- Event delegation drives important bundlers and tools like webpack. If this is a feature, should it be written in a way to interop with other plugins features? IE: extended, transpiled languages (events for TS, Flow, CJS, etc.).
### Esprima
- Limiting features can yield higher parse performance. Where is this relevant, can this help establish a base
### Babylon/Babili
- Program Flow is important and can be leveraged for optimizations, compression, minimizing. However the level of optimization is based on the amount of knowledge known (types, etc.). Can this be applied to more than just ES6?