Nit: Acorn's *output* is based on Esprima. Its code is *not* and hasn't been for a few years now. It started a fork of Esprima, but it wasn't long before it was rewritten the first time.
----- Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Mon, Sep 16, 2019 at 1:58 AM kai zhu <kaizhu...@gmail.com> wrote: > > adding datapoint on application in code-coverage. > > a builtin parser-api would be ideal (and appreciate the insight on > implementation difficulties). > lacking that, the next best alternative i've found is acorn (based on > esprima), > available as a single, embedabble file runnable in browser: > > ```shell > curl https://registry.npmjs.org/acorn/-/acorn-6.3.0.tgz | tar -O -xz > package/dist/acorn.js > acorn.rollup.js > ls -l acorn.rollup.js > -rwxr-xr-x 1 root root 191715 Sep 15 16:49 acorn.rollup.js > ``` > > i recently added es9 syntax-support to in-browser-variant of istanbul by > replacing its aging esprima-parser with acorn [1]. > ideally, i hope a standardized ast will be available someday, and get rid of > acorn/babel/shift altogether (or maybe acorn can become that standard?). > even better, is if [cross-compatible] instrumentation becomes a common > bultin-feature in engines, and get rid of istanbul. > > chrome/puppeteer's instrumentation-api is not yet ideal for my use-case > because it currently lack code-coverage-info on branches (which > istanbul-instrumentation provides). > > [1] istanbul-lite - embeddable, es9 browser-variant of istanbul code-coverage > https://kaizhu256.github.io/node-istanbul-lite/build..beta..travis-ci.org/app/ > > > > On Sun, Sep 15, 2019 at 9:08 AM David Teller <dtel...@mozilla.com> wrote: >> >> In theory, it should be possible to have both modes, if the parser is >> designed for it. Unfortunately, that's not the case at the moment. >> >> Mozilla has recently started working on a new parser which could be used >> both by VMs and by JS/wasm devs. It might help towards this issue, but >> it's still early days. >> >> Cheers, >> David >> >> On 15/09/2019 13:09, Jack Works wrote: >> > Happy to see standard ast in binary ast proposal. >> > >> > For compiler, it can have a "slow" mode when parsing with this parser >> > API and still use fast code generation in other cases. But unfortunately >> > it seems there are much more work than I think to provide such an API. >> > >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
