by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 19 2019 13:45

    aladdin-add on aladdin-add-patch-1

    (compare)

  • Jul 19 2019 13:45

    aladdin-add on master

    Docs: add deprecation notice Update README.md Merge pull request #355 from ch… (compare)

  • Jul 19 2019 13:45
    aladdin-add closed #355
  • Jul 19 2019 13:43

    aladdin-add on aladdin-add-patch-1

    Update README.md (compare)

  • Jul 19 2019 13:43
    aladdin-add synchronize #355
  • Jul 19 2019 13:42
    aladdin-add review_requested #355
  • Jul 19 2019 13:42
    aladdin-add opened #355
  • Jul 19 2019 13:42

    aladdin-add on aladdin-add-patch-1

    Docs: add deprecation notice (compare)

  • Jul 19 2019 13:36
    aladdin-add closed #353
  • Jul 19 2019 13:35
    KFlash commented #353
  • Jul 19 2019 13:34
    aladdin-add edited as member
  • Jul 19 2019 13:32
    aladdin-add closed #351
  • Jul 19 2019 13:32
    aladdin-add commented #351
  • Jul 19 2019 13:31
    aladdin-add commented #353
  • Jul 19 2019 13:31
    aladdin-add commented #353
  • Jul 19 2019 13:30
    aladdin-add closed #318
  • Jul 19 2019 13:30
    aladdin-add commented #318
  • Jul 19 2019 13:30
    aladdin-add closed #332
  • Jul 19 2019 13:30
    aladdin-add commented #332
  • Jul 19 2019 13:30
    aladdin-add commented #336
Alan Pierce
@alangpierce
Hey @KFlash, is there a good technical summary of what makes Cherow fast? (I'm planning to read and dig into the code, just curious if you have a higher-level summary.) I've been working on a Babylon fork to compile TypeScript, Flow, and JSX ( https://github.com/alangpierce/sucrase ) and have done a number of optimizations, but it looks like Cherow is still faster ( https://github.com/alangpierce/sucrase/issues/227#issuecomment-394101229 ). In my case, I removed AST generation (since I don't need it for my use case), removed lots of validation, simplified the state and state cloning, and use a fancy decision tree approach to determining keywords, but Cherow seems to still be faster.
Philippe
@elsassph
Ok nice: 30Mb single JS file :slightly_smiling_face:
Parsed in: 5138ms // acorn
Parsed in: 3519ms // cherow
Pig Fang
@g-plane
ping @KFlash
Fred Kleuver
@fkleuver
@/all we're locking 1.6.8 onto branch 1.x, and 2.0 work will continue on the master branch
2.0 branch will go away
Kenny F.
@KFlash
@/all v. 2.0 will land in 2 weeks.
Brad Jones
@bradjonesca
This is looking very promising ... looking forward to version 2.0!
Rizky Luthfianto
@rilut
Cool, looking forward to the next versions of cherow :smile:
Hi, just curious, can I use cherow for shallow parsing only? So I just want to check whether an expression is FunctionExpression/ArrowFunctionExpression or ClassExpression, then I'll just get the required parameters list or constructor list
That way, we don't have to really check whether the methods/properties in the class/function is really valid. Is this possible/important?
Kenny F.
@KFlash
@rilut It's not possible in 1.6.8, but I can add it to v. 2.0. Could you open an issue ticket regarding this, and describe it in details so I can track it?
Kenny F.
@KFlash
2.0 is delayed. But finished within a month
Kenny F.
@KFlash
Delays with cherow due to RL issues and personal crisis. But hopefully I will start working on finishing v. 2.0 mid of October
Matthew Cheok
@matthewcheok
Probably a silly question but I couldn't install the cherow-ts package via npm. Is this available?
Pig Fang
@g-plane
That's not complete yet.
Kenny F.
@KFlash
Sorry delays with Cherow 2
A lot of things happened in my RL but I expect to start again in 7 days. I'm awaiting my government license again this week
By December 12 latest I'm back on track and I will make sure that Cherow stay as the fastest ES parser in the world. Also several other changes will be added and the parser will be 20% smaller than Acorn
Kenny F.
@KFlash
I'm completely retired now and going to give "all in" on this version to give something back to ES community. When I'm done. I'm done and hope others van do PR to keep cherow up to date for the future because I feel my time as a developer are soon to end.
Harry Solovay
@harrysolovay
I'm working on a project that needs to be able to run JavaScript of varying supersets (might be TypeScript, babel-dependent, reason... etc.). In order to make this work, I need to use different version of the Cherow parser to achieve the same AST. My hope is that there's a good tool out there that I can use to detect the language features used in the inputted code. Does anyone know how I might achieve this? (unfortunately, reading the file extension isn't an option in my use case). Any insights would be greatly appreciated. Thank you!
Fred Kleuver
@fkleuver
You want to use duck-typing technique to determine the parsing strategy for a file?
That'll be a very hard problem to solve if performance is even remotely a concern
What are you trying to do exactly?
Kenny F.
@KFlash
A demo of the upcoming Cherow 2.0 is up now. Click on the link in the readme. This is just to give a look and feel of how it will be.
Note that AnnexB has become an option and you can now parse with and without web compability.
The performance for Cherow 2.0 is around 2% slower than 1.6x due to the fact full scoping and lexicals have been implemented and do validations as you parse, but Cherow is still twice as fast as Acorn
nchanged
@nchanged
Hey guys, I am the founder of FuseBox (https://github.com/fuse-box/fuse-box) I am considering to use cherow in v4 (next version) as a replacement to Acorn (To my big surprise it's actually faster). Wanted to ask a few question, do you support all of the stuff that acorn supports, as in jsx, dynamic imports, and all the goodies? fusebox is a bundler it's important to keep up with the standards. And of course, If I go with using cherow you will hear from me more ;-) Thanks guys, amazing job!
Kenny F.
@KFlash

@nchanged v. 1.6x have all the things that Acorn have plus support for Stage 3 proposals. v. 2.0 exist on Master branch, but haven't been released to NPM yet. I'm waiting for @fkleuver to fix that...... V. 2.0 support more than Acorn, but lack JSX support ATM.

Regarding performance. Yes. Cherow is the fastest parser :)

nchanged
@nchanged
Oh there is no JSX yet? (
That's kind of a show stopper
Fred Kleuver
@fkleuver
It has been released to NPM already under the dev tag guys, so if you want to try the new V2.0 you just install npm i cherow@dev, that'll give you cherow@1.6.8-dev.20190313 or something. The master branch is published directly to the dev channel every night
nchanged
@nchanged
jsx has been released ?
Kenny F.
@KFlash
For v. 1.6x, not yet for 2.x.
nchanged
@nchanged
do you have any ETA on when JSX will be stable?
for me there is no rush, I am not even nearly done with my refactors ;-)
Kenny F.
@KFlash
It depends on @fkleuver I guess. He is in charge of the project now. So I guess when he have time and no job or other tasks he need to fix.
nchanged
@nchanged
brilliant
nchanged
@nchanged
hey guys, just noticed, that cherow@dev is slower compared to the stable version by 2ms xD
not a big difference tho, but still
parseWithAcorn: 12.069906891572593ms (101 runs)
parseWithCherow: 9.184455624458813ms (101 runs)
catching up with acorn
used to be 7ms
Kenny F.
@KFlash
@fkleuver works on the performance, and will separate the scoping from the main code. That will make it faster again.
V. 1.6x didn't have any scoping implemented, but Acorn has. Still faster, but will be faster again soon
Kenny F.
@KFlash
Everyone! Cherow 2.0 will be published to NPM soon as @fkleuver get around to it. I'm retired, but will continue to fix bugs if they pop-ups but I'm slow to respond.
nchanged
@nchanged
hey guys, how can I get cherow to parse jsx?
1.6.8-dev.20190514 doesn't like it
nchanged
@nchanged
@fkleuver
Maurício Kishi
@mrkishi

Hey, folks. I'm sorry for bothering you with a silly question, but I looked for info on this everywhere and came up empty.

Why does cherow use generics on top of discriminated unions to implement its estree ast nodes? Are there benefits over defining type: 'Type' in the interface itself or was this an stylistic choice? I just couldn't figure it out.

Thanks!

Kenny F.
@KFlash
@fkleuver are the right person to reply to this.
Maurício Kishi
@mrkishi
Thanks, @KFlash. It might not be fkleuver's reasoning, but I realized with generics we're forced to specify <T> when using an intermediate interface, so we're less likely to accidentally use them when we meant to use an actual leaf type. That's a good enough reason to use them imo!
Kenny F.
@KFlash

While we waiting for @fkleuver to publish Cherow 2.0 - take a look at Meriyah

https://github.com/meriyah/meriyah

It's my "little" retirement project :)