cherow - npm Package Compare versions
Comparing version 0.0.33 to 0.0.34
@@ -46,82 +46,2 @@ ## Benchmarks | ||
| #### For | ||
| **for(x, y;;);** | ||
| - Cherow x 947,914 ops/sec ±3.06% (88 runs sampled) | ||
| - Esprima x 489,137 ops/sec ±6.95% (81 runs sampled) | ||
| - Acorn x 111,197 ops/sec ±11.14% (78 runs sampled) | ||
| - Fastest is Cherow | ||
| **for (let {} = null; ; ) {}** | ||
| - Cherow x 651,317 ops/sec ±2.87% (84 runs sampled) | ||
| - Esprima x 281,314 ops/sec ±4.34% (79 runs sampled) | ||
| - Acorn x 100,009 ops/sec ±3.38% (83 runs sampled) | ||
| - Fastest is Cherow | ||
| #### For In | ||
| **for(let [a=b in c] in null);** | ||
| - Cherow x 206,075 ops/sec ±2.10% (85 runs sampled) | ||
| - Esprima x **Esprima can't parse this** | ||
| - Acorn x 89,805 ops/sec ±5.67% (86 runs sampled) | ||
| - Fastest is Cherow | ||
| **for({a=0} in b);** | ||
| - Cherow x 628,722 ops/sec ±1.30% (90 runs sampled) | ||
| - Esprima x 313,842 ops/sec ±3.73% (85 runs sampled) | ||
| - Acorn x 92,887 ops/sec ±14.82% (83 runs sampled) | ||
| - Fastest is Cherow | ||
| #### For Of | ||
| **for(var a of b);** | ||
| - Cherow x 568,955 ops/sec ±4.70% (78 runs sampled) | ||
| - Esprima x 316,343 ops/sec ±2.84% (89 runs sampled) | ||
| - Acorn x 107,249 ops/sec ±1.52% (90 runs sampled) | ||
| - Fastest is Cherow | ||
| **for ({ x: [ x ] } of [{ x: null }]) {}** | ||
| - Cherow x 393,523 ops/sec ±1.35% (91 runs sampled) | ||
| - Esprima x 102,358 ops/sec ±0.83% (95 runs sampled) | ||
| - Acorn x 88,635 ops/sec ±0.86% (93 runs sampled) | ||
| - Fastest is Cherow | ||
| #### JSX | ||
| **<span/>** | ||
| - Cherow x 1,330,443 ops/sec ±2.33% (90 runs sampled) | ||
| - Esprima x 560,163 ops/sec ±6.20% (80 runs sampled) | ||
| - Acorn x 119,288 ops/sec ±8.05% (87 runs sampled) | ||
| - Fastest is Cherow | ||
| **<input disabled />** | ||
| - Cherow x 831,651 ops/sec ±0.38% (94 runs sampled) | ||
| - Esprima x 224,494 ops/sec ±4.11% (78 runs sampled) | ||
| - Acorn x 117,329 ops/sec ±2.45% (85 runs sampled) | ||
| - Fastest is Cherow | ||
| **function *g() { yield <h1>Hello</h1> }** | ||
| - Cherow x 170,258 ops/sec ±3.36% (81 runs sampled) | ||
| - Esprima x 83,754 ops/sec ±4.06% (83 runs sampled) | ||
| - Acorn x **Acorn fail to parse this one** | ||
| - Fastest is Cherow | ||
| **<strong><em></em></strong>** | ||
| - Cherow x 429,999 ops/sec ±2.05% (90 runs sampled) | ||
| - Esprima x 146,011 ops/sec ±2.57% (85 runs sampled) | ||
| - Acorn x 89,173 ops/sec ±4.58% (83 runs sampled) | ||
| - Fastest is Cherow | ||
| #### Async functions | ||
@@ -128,0 +48,0 @@ |
| { | ||
| "name": "cherow", | ||
| "version": "0.0.16", | ||
| "version": "0.0.34", | ||
| "description": "Fast, standard-compliant ECMAScript parser written in ECMAScript", | ||
@@ -8,6 +8,2 @@ "main": "dist/cherow.js", | ||
| "license": "MIT", | ||
| "engines": { | ||
| "node": ">= 5.4.1 < 6", | ||
| "npm": ">= 3.5.3" | ||
| }, | ||
| "homepage": "https://github.com/cherow/cherow", | ||
@@ -14,0 +10,0 @@ "repository": { |
179
README.md
@@ -1,142 +0,133 @@ | ||
| # Cherow | ||
| [](https://travis-ci.org/cherow/cherow) | ||
| *Work in progress* | ||
| Cherow is a very fast, standard-compliant [ECMAScript](http://www.ecma-international.org/publications/standards/Ecma-262.htm) parser written in ECMAScript. | ||
| **ANNOUNCEMENT** I have stopped playing around, and gone into a mode where I'm actually finishing this parser. | ||
| It strictly follows the ECMAScript® 2018 Language Specification and should parse acc. these specifications | ||
| Everything parses now after the ECMA specifications. | ||
| It's safe to use in production. | ||
| It's now save to use Cherow in development, and it covers the same thing as Esprima and Acorn | ||
| does. It even parse a lot of cases the mentioned parsers fails on. | ||
| Please note that I'm not done with this parser. The development are done in the the *dev branch*. | ||
| In fact. Cherow now parses everything after the ECMAScript specs. | ||
| ## Features | ||
| **NOTE!!** No point to open issue tickets. I know what I'm doing : ) | ||
| - Full support for ECMAScript® 2018 [(ECMA-262 8th Edition)](http://www.ecma-international.org/publications/standards/Ecma-262.htm) | ||
| - Stage 3 proposals (*experimental*) | ||
| - Support for JSX, a syntax extension for React | ||
| - Skips shebang comment nodes by default | ||
| - Optional tracking of syntax node location (index-based and line-column) | ||
| - 4650 unit tests with full code coverage | ||
| It's safe to use Cherow now, but I'm still not willing to move the code to Master branch until the internals are fixed, and | ||
| the my remaining TODO are fixed. | ||
| ## ESNext features | ||
| Over 4400 unit tests should tell you that Cherow works! | ||
| `Stage 3` features support. This need to be enabled with the `next` option | ||
| Be aware that the code will change rapidly as I do progress. | ||
| - Import() | ||
| - Asynchronous Iteration | ||
| - Rest/Spread Properties | ||
| - Optional catch binding | ||
| - Regular Expression's new `DotAll` flag | ||
| ## Current stage | ||
| ## V8 experimental features | ||
| At current stage Cherow are working 100%, but not optimized. It's tested against both Acorn and Esprima and | ||
| I'm also parsing huge libraries with this parser - both ES5 and ES6 code. | ||
| This need to be enabled with the `v8` option | ||
| To parse something, you can do: | ||
| - Do expressions | ||
| ```js | ||
| implement { parseMOdule, parseScript } from 'cherow'; | ||
| ## Options | ||
| // parse in sloppy mode | ||
| parseScript('function foo() { return "bar"; } '); | ||
| * `next` - Enables `ECMAScript Next` support and let you use proposals at `stage 3` or higher such as `Dynamic Import`. | ||
| * `raw` - Enables the raw property on literal nodes (*Esprima and Acorn feature*) | ||
| * `comments` - Enables option to collect comments. Optional; Either array or function. Works like [Acorn](https://github.com/ternjs/acorn) onComment. | ||
| * `tokens` - If enabled each found token will be returned as either an function or an array (*work in progres*) | ||
| * `ranges` - Enables the start and characters offsets on the AST node. | ||
| * `locations` - Enables location tracking. (*4 min fix, but on hold for now*) | ||
| * `jsx` - Enables JSX | ||
| // parse inmodule code | ||
| parseModule('function foo() { return "bar"; } '); | ||
| ## API | ||
| // parse and get a ESTree output like Esprima | ||
| Cherow can be used to perform syntactic analysis of Javascript program. | ||
| parseScript('function foo() { return "bar"; } ', { raw: true, directives: true }); | ||
| ```js | ||
| // parse and get a ESTree output like Acorn | ||
| // Parsing script | ||
| cherow.parseScript('const fooBar = 123;'); | ||
| parseScript('function foo() { return "bar"; } ', { raw: true, ranges: true }); | ||
| // Parsing module code | ||
| cherow.parseModule('const fooBar = 123;'); | ||
| ``` | ||
| ## Parsing with options | ||
| ## Roadmap | ||
| Mostly get tests to fail where they should fail according to TC39. | ||
| ```js | ||
| 1. Make sure things parses as they should | ||
| 2. General cleanup and reduce amount of bitmasks | ||
| 3. Reduce code size | ||
| // Parsing script | ||
| cherow.parseScript('const fooBar = 123;', { ranges: true, raw: true, next: true}); | ||
| ## Important | ||
| ``` | ||
| JSX are 99% completed and template are missing support for escaped sequences. This is done with purpose. TypeScript handle JSX and templates differently so this will be fixed after the TS parser code have been implemented. | ||
| ## Comments | ||
| # Development process | ||
| Single line, multiline and HTML comments are supported, and can be collected as well. Shebang comment node - `#!foo` - are | ||
| skipped by default, and can't be collected. | ||
| That is the most complex things I'm doing. I'm using `http://astexplorer.net/` to keep track on what fails and doesn't fail in various parsers. I'm also | ||
| running `SpiderMonkey`, `V8`, and testing it against `NodejS` itself to validate if I'm doing the right things. | ||
| ### Collecting comments | ||
| Beside that. For every change I do in the code base, I'm parsing around 30 different libraries every time just to validate that I didn't break anything! | ||
| Collecting comments works just the same way as for Acorn | ||
| ```js | ||
| On top of that I'm running various benchmarks. | ||
| // Function | ||
| cherow.parseScript('// foo', | ||
| { | ||
| comments: function(type, comment, start, end) {} | ||
| } | ||
| ); | ||
| So everyone can make sure that the thing I'm pushing to this repo actually are working :) | ||
| // Array | ||
| const commentArray = []; | ||
| cherow.parseScript('// foo', | ||
| { | ||
| comments: commentArray | ||
| } | ||
| ); | ||
| ## Location tracker | ||
| ``` | ||
| As it is now this parser have options you can use to get the same AST output as either Esprima or Acorn. By default Esprima doesnt have any location tracking on the node. Acorn has. For that use `ranges: true` as the option when you parse. | ||
| ## Acorn and Esprima differences | ||
| Column and lines are in progress still. | ||
| The main difference between Cherow and Acorn and Esprima is that the mention libraries either doesn't parse everything | ||
| according to TC39, or they doesn't fail as they should according to the ECMAScript specs. | ||
| Note there exist a difference between how Esprima and Acorn calculating the ranges. You can see this in template string with an simple identifier. Acorn set the identifier start value to 2 (*after template head*). Esprima calculating it as 0. | ||
| Cherow parses everything after the specs, and fails 90% after the specs (*work in progress*). | ||
| Due to this differences I'm still thinking how to do this. Example `Espree` uses Acorn, but uses Esprima location tracking layout. | ||
| However. Column and lines can be activated with `ranges: true`, but will output wrong values due to the fact this is far from completed. | ||
| ## Performance and benchmarks | ||
| I may end up adding a Esprima and Acorn mode option due to backward compability. | ||
| The most important thing for an ECMAScript parser is the performance. Especially important is it when the parser is a | ||
| dependency in other libraries. Poor performance will slow down the main library. | ||
| ## Error tracking | ||
| Cherow has been developed from scratch with only one goal - performance. | ||
| This is an complex process. Mostly all open source parsers report either wrong location or wrong token position. One example here | ||
| is Esprima wich is failing on invalid computed property. `({[x]})`. In this case Esprima will throw and report the last brace - `}` - as the wrong token. In fact this has nothing to do with the invalid computed shorthand property. | ||
| You can find the the benchmarks [here](BENCHMARK.md) | ||
| Cherow are designed from ground up to fix all this things and report errors correctly. In mentioned case, Cherow will report the first bracket - `[` - as the wrong token. Wich is the start of the computed property. | ||
| ## ESTree | ||
| Here is an example on how I do it. | ||
| Cherow outputs a sensible syntax tree format as standardized by [ESTree project](https://github.com/estree/estree), and does | ||
| not add any "extra" properties to any of it's node like [Esprima](https://github.com/jquery/esprima). | ||
| It should fail on both `function static() { "use strict"; }` and `"use strict"; function static() {}` with correct error location. Note the `"use strict";` | ||
| directive in the functions body. | ||
| However. There is a small difference from other parsers because Cherow outputs a `await` property on the `ForStatement` node. | ||
| This because of the support of `For Await` and `Async Generators`. | ||
| So the source code for it, will look like this: | ||
| ```js | ||
| // if allready in strict mode code, thow | ||
| this.error(Errors.UnexpectedStrictReserved); | ||
| // ... else record current location and mark | ||
| // that we found a reserved word | ||
| this.errorLocation = this.trackErrorLocation(); | ||
| this.flags |= Flags.ReservedWord; | ||
| ``` | ||
| In the functions body I check if the parser state are in strict mode, and if that's the case, I check for the bitmask and throw the | ||
| error at the recorded location. | ||
| ## Contribution | ||
| You are welcome to contribute. As a golden rule - always run benchmarks to verify that you haven't created any | ||
| bottlenecks or did something that you shouldn't. | ||
| No magic! Just simple coding. | ||
| *Terms of contribution:* | ||
| ## Performance | ||
| Once again. Allmost all open source parsers have two or more deopts. Cherow are designed to avoid this. A good example is when you are accessing another object shape for checking values - `obj.type === "AssignmentExpression"`. This can *and* will cause an deopt. | ||
| Performance is one out of many reasons why developing this parser take so long time. | ||
| ## TC39 | ||
| At this stage 90% TC39 compatible. There exist a few tests that doesn't fail when they | ||
| should. I'm working on it :) | ||
| And there can be bugs in the bleeding edge cases like Stage 3 (*use next Option*). One example | ||
| here is object rest spread. A few weeks ago the specs changed again, and I haven't updated it yet | ||
| ## Other | ||
| ### Tokenizing. | ||
| It's there, but work in progress. Use `tokens: true`. This is work in progress. See *TODO*. | ||
| ### Comment collecting | ||
| It's there, and working. It should work just like Acorn's `onComment`. Just do `comments: true` | ||
| ### Tolerate mode | ||
| I still have to find a valid usecase for it. Once I do, I will add it. | ||
| - Think twice before you try to implement anything | ||
| - Minimum 1.5 mill ops / sec for light weight cases, and 800k - 1 mill ops / sec for "heavy" cases | ||
| - Avoid duplicating the source code | ||
| - Create tests that cover what you have implemented |
Sorry, the diff of this file is too big to display
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Manifest confusion
Supply chain riskThis package has inconsistent metadata. This could be malicious or caused by an error when publishing the package.
Found 1 instance in 1 package
Improved metrics
- Number of package files
- increased by16.67%
7
- Number of medium supply chain risk alerts
- decreased by-100%
0
Worsened metrics
- Total package byte prevSize
- decreased by-0.46%
581433
- Number of lines in readme file
- decreased by-6.29%
134
No dependency changes