-
-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace babylon with @babel/parser, and upgrade all babel dependencies #307
Conversation
rjatkins
commented
Jan 25, 2019
- Note that @babel/parser 7+ no longer supports wildcard plugins config, which forces us to be explicit. See https://babeljs.io/docs/en/babel-parser#plugins for the documented list of plugins
* Note that @babel/parser 7+ no longer supports wildcard plugins config, which forces us to be explicit. See https://babeljs.io/docs/en/babel-parser#plugins for the documented list of plugins
177a4bb
to
a13d9c8
Compare
Codecov Report
@@ Coverage Diff @@
## master #307 +/- ##
==========================================
- Coverage 98.39% 98.11% -0.29%
==========================================
Files 32 30 -2
Lines 561 477 -84
==========================================
- Hits 552 468 -84
Misses 9 9
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #307 +/- ##
=======================================
Coverage 98.39% 98.39%
=======================================
Files 32 32
Lines 561 561
=======================================
Hits 552 552
Misses 9 9
Continue to review full report at Codecov.
|
@rjatkins thank you very much on contributing on this project. Any breaking changes between babylon and @babel/parser? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat 👏
https://babeljs.io/docs/en/v7-migration-api#babel-parser-known-as-babylon lists the breaking changes in babel/parser. Aside from * plugins being removed, the default decorators spec implementation changed, and the class constructor call proposal was removed, because it was rejected by the tc39 committee. I should note that I've left flow disabled by default, which may or may not be a good idea. We might have to create a specific flow parser to handle that instead. You definitely don't want flow and typescript enabled at the same time. |
I'm pretty much OK with flow being disabled :) Thank you so much for contributing! |