-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Babel 7 Take 2 #23424
Babel 7 Take 2 #23424
Conversation
4da4aac
to
660d82b
Compare
@samouri I'd be happy to help y'all upgrade to v7, and if you want to do a video call to talk let me know. Also I started work on https://github.com/babel/babel-upgrade which may help with upgrading as well as http://new.babeljs.io/docs/en/next/v7-migration.html. I'm
|
Hi @hzoo, First off, thank you so much for all of your work on Babel! Not only has it been an amazing tool for Calypso, the grace and openness with which you run Babel is a source of inspiration. I think we successfully figured out a lot of the important bits as part of our first attempt: #23026 -- all of the explanations of the code changes are there. I'd still be excited to have your expert advice on our We reverted because we noticed that the wrapNativeSuper() helper was incompatible with ie11 -- turns out we hit an unfortunate bug affecting the beta40 release that seems to have been fixed with the beta41 release. We are in the process of adding automated testing to make sure we always test pull requests in ie11 before merging which should prevent us from making the same mistake in the future. One question for you would be: is the Babel 7 beta ready for projects like ours to use in production? |
@hzoo: We'd still love to upgrade to 7 if you have time to answer our questions! The main questions are around why is babel7 still considered a beta and if it is suitable for production projects. Create React App seems to think so. My impression is that bugs are equally likely to come out in a post-v7 release as it is during these beta releases (we need be better at testing). That the reason babel is still in beta is so that you can you can still release breaking changes -- which usually don't affect applications. All of this is total conjecture on my part, and we'd be very appreciative of an answer! Thanks again, |
Yeah I think it should be ready for apps in prod. I had upgraded us at Behance to it while I was working there the whole time we were in beta. And yes your impression is correct - it's not really about bugs per se since we didn't change a lot of core things just config changes. There is one breaking change we want to do before an RC which is babel/babel#7358. Otherwise we it's ready to be released given we removed a bunch of other stuff we wanted to do (feature creep is pretty easy for a major release + oss project with all volunteers) |
5bc7594
to
bb3a319
Compare
.babelrc.js
Outdated
test: { | ||
plugins: [ | ||
'./server/bundler/babel/babel-lodash-es', | ||
[ 'transform-builtin-extend', { globals: [ 'Error' ] } ], |
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.
I think this should be covered by the new PR to the classes transform itself? https://twitter.com/left_pad/status/940723982638157829
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.
Looks right to me, thanks for looking! I've removed the unnecessary transform
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.
The transform-builtin-extend
was added in #19621 to enable extending SchemaError
from Error
. If I remove the transform from the Babel 6 config in master, the tests in client/state/data-layer/wpcom/concierge
will start failing.
In this Babel 7 branch, these tests succeed even after the transform is gone. Therefore the removal is good and has been successfully tested 👍
package.json
Outdated
"babel-preset-env": "1.6.0", | ||
"babel-preset-stage-2": "6.24.1", | ||
"babel-register": "6.24.1", | ||
"babel-register": "6.26.0", |
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.
This should be @babel/register
or removed right?
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.
After investigation it looks like we are still using babel-register
in a single-location which initially made me think that switching to @babel/register
would be correct. But after closer inspection I can't figure out why its using babel-register at all. I'll see if i can remove it now here: #24085
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.
merged #24085 and removed the babel-register
!
.babelrc.js
Outdated
{ async: isCalypsoClient && codeSplit }, | ||
], | ||
'@babel/plugin-proposal-export-default-from', | ||
'@babel/plugin-proposal-export-namespace-from', |
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.
FWIW, this is already included in stage-2
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.
Thanks for letting me know! I'll remove it then 👍
// it very slightly diverges from spec but also is more concise. | ||
// see: http://new.babeljs.io/docs/en/next/v7-migration.html#babel-plugin-proposal-class-properties | ||
[ '@babel/plugin-proposal-class-properties', { loose: true } ], | ||
[ '@babel/plugin-transform-classes', { loose: false } ], |
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.
This was only done for backwards compat with v6? Although I guess you need it for extends Error
to work I believe. Loose would be smaller, or you could just use loose
for all of the transforms if you are really trying to save bytes.
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.
. Loose would be smaller, or you could just use loose for all of the transforms if you are really trying to save bytes.
I tried that at first, but ~20 of our unit tests started failing. While they were all easily fixable, I'm worried that there are probably subtle failures that would happen within the app that we wouldn't catch for a long time
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.
@jsnajdr built a tool called iscalypsofastyet that measures how branches affect bundle sizes. I'll do another measurement to see the exact difference and make sure it is worth losing spec compliance
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.
This is also something I wish we could help with like showing the different options and running tests or something like that - what changes and doing a diff of the output between different builds/spec
Also where is |
@hzoo it's not at the moment, we're just using transform-runtime and warning folks that use some es6 prototype methods. We'd like to move to using the polyfill but have not historically for size reasons. |
@@ -1,6 +1,6 @@ | |||
/** @format */ | |||
|
|||
const types = require( 'babel-types' ); | |||
const types = require( '@babel/types' ); |
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.
FYI, this could be deleted and moved to the line before as
module.exports = function({ types }) {
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.
nice! I'll update that now
@@ -15,7 +15,7 @@ const SharingPreviewModal = ( props ) => { | |||
const { | |||
isVisible, | |||
onClose, | |||
...previewProps, | |||
...previewProps |
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.
Nit: I'd expect prettier to maintain this comma. File is missing /** @format */
.
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.
It shouldn't because it's "spec" behavior that we changed in Babel 7. For context, It was in a v6 patch before and it "broke" react-native so it was moved to a v7 change. And Prettier uses the Babel parser. I think it's mentioned in the description ^
Basically a rest param is always last so it doesn't need a comma
edit: link babel/babylon#149 (comment)
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.
TIL, thanks! It is nicely mentioned in the description. I've also verified that prettier handles this correctly.
Ok cool, that's fine. Yeah my point above ^ is that when I mean to use the polyfill it only imports a subset of the polyfill (although it probably needs better testing) to be robust. Again if y'all want to do a call or something we can chat about it. |
updates since revert update to latest versions fix strange case of props rest expansion no need for transfrom-extend-builtin
4a1d6d7
to
32fa946
Compare
Here is a comparison of some of the minified sizes of the outputted code (not gzipped) from the loose and spec versions (only applying loose to class and template-literal transforms) You will notice that for vendor there is not a signficant difference, which makes sense considering most libraries are already transpiled and don't utilize Class definitions takes up ~120 characters in spec instead of ~40 in loose. Our own code is React based and heavily uses
|
Yeah, something we are trying figure out is regarding compiling |
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.
🐑
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.
LGTM! Tested out fine.
Reverts #23389
Attempt 2 at #23026
Original PR Notes:
summary
Babel 7 has undergone ~40 iterations of alpha releases and another 40 of beta releases. It is very stable and has numerous features that Calypso development can benefit from. Those features include:
.babelrc.js
vs..bablrc.json
)<></>
Babel docs on the upgrade: http://new.babeljs.io/docs/en/next/v7-migration.htm
changes made
babel-core
-->@babel/core
,babel-preset-env
-->@babel/env
,babel-preset-react
-->@babel/react
,babel-types
-->@babel/types
,babel-core
to the bridge which is necessary for anything having babel as a peer dependency -- aka jest.transform-class-propertites
to be "loose" which mimics babel6 behavior and is much more concise than the new spec client format based onObject.defineProperty
[1]babelrc.json
-->babelrc.js
which simplifies the webpack configs.Question for the reviewer:
env.test
within webpack considering it should be ignored by babel unlessNODE_ENV=test
to test
appendix
[1]: Here is an illustration of the loose and strict methods for transforming class variables.
For the following es6 code
Loose babel transformation would get us: (default in babel 6)
Strict transformation would return more verbose code: