-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 6 #4862
Conversation
Current failures are due to some node@4 incompatibilities in babel6-plugin-strip-heimdall that have been fixed upstream. I just need to confirm it is released and update here. |
Everything is working locally (I believe), but I'd love for folks to test (using node@6 or higher for now) and report back. |
@runspired - Can you release an updated babel6-plugin-strip-heimdall with node@4 support? |
@rwjblue yep! |
OK, this is ready for review. It has feature parity with prior babel@5 configuration, and fixes a bug in our globals build (which makes our 2.13.0-beta.1 bower builds completely broken). The goal with this work is to get ember-cli@2.13 to only include addons that are using babel@6, as such I'd like to get this cherry-picked into beta branch once reviewed. |
@bmac - I have kept "semantic" commits so far, but I don't mind squashing if that makes cherry-picking easier... |
"babel-plugin-transform-es2015-parameters": "^6.23.0", | ||
"babel-plugin-transform-es2015-shorthand-properties": "^6.22.0", | ||
"babel-plugin-transform-es2015-spread": "^6.22.0", | ||
"babel-plugin-transform-es2015-template-literals": "^6.22.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.
is the assumption here that we build and release the globals version ourselves and thus these don't need to be dependencies?
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.
@rwjblue this was the only thing I spotted I had any question on, otherwise +1 LGTM
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.
Yes, the only place we use these directly is in our own build of the addon itself (e.g. from ember-cli-build.js
in this repo which is not used by any other consumers).
This may not be an issue, normal installation seems to work fine. I think mixing babel 5 and babel6 in dev mode may have just made yarn get emo in Something seems fishy others should check to see if its not just an issue on my end:
https://gist.github.com/stefanpenner/b3e96ba10a9af08dfc5c136a0c53b292 My warm/colde initial builds are also quite slow likely do to hash-for-dep having to traverse all these dependencies. |
When installing the babel6 branch in a project via yarn add "emberjs/data#babel-6" All appears well. Not quite sure in-project I was having issues. |
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.
babel helpers appear to be duplicated:
function _classCallCheck(instance, Constructor) {
if (!(instance instanceof Constructor)) {
throw new TypeError("Cannot call a class as a function");
}
}
var _createClass = function () {
function defineProperties(target, props) {
for (var i = 0; i < props.length; i++) {
var descriptor = props[i];
descriptor.enumerable = descriptor.enumerable || false;
descriptor.configurable = true;
if ("value" in descriptor) descriptor.writable = true;
Object.defineProperty(target, descriptor.key, descriptor);
}
}
return function (Constructor, protoProps, staticProps) {
if (protoProps) defineProperties(Constructor.prototype, protoProps);
if (staticProps) defineProperties(Constructor, staticProps);
return Constructor;
};
}();
class syntax uses verbose (and hard to debug) array of pojo descriptors. Something #4864 addresses in babel 5. Maybe loose mode is missing?
_createClass(RecordArrayManager, [{
key: 'recordDidChange',
value: function recordDidChange(internalModel) {
// TODO: change name
// TODO: track that it was also a change
this.internalModelDidChange(internalModel);
}
}, {
do we expect? I thought @rwjblue added some loose mode for this guy to babel 6.
Object.defineProperty(exports, "__esModule", {
value: true
});
Yes, we are not using loose. I'll fix.
Yes, we still expect |
👍 |
OK, updated and ensured that the asset output is in The appveyor failure seems related to an SSL issue, but one of the try results had already passed at this point so I think its fine... @bmac I'd like for this to land into ember-data@2.13.0-beta.2, would you like me to squash the commits down to make that easier to cherry pick? |
Yes please @rwjblue. |
just did a quick check, output looks good. If you can double check build and yarn install times doesn't regress, we should be good! |
Before changes:
After changes:
It seems basically the same or slightly better in almost all of the things I measured. |
Thanks @rwjblue. 🎉 |
Just wanted to give a heads up that this change caused me to get some cryptic errors that took a little bit of time to track down.
So I tracked this down to the fact that we had the following in our package.json:
I guess maybe this is kind of legacy? The right was seems to be to include the following in my
I'm not sure how many people have this in their package.json, but if it's a sizable amount it might be worth mentioning in some upgrade notes / blog post. Just wanted to call it out. |
Interesting!! I thought we disabled the normal |
That makes two of us. Another engineer on my team added decorators and when I saw it I immediately thought, why is that in the Either way we had found that EDIT: And if it's not clear why this is a gun foot, it's because the
|
cc @stefanpenner I think you had to do some things to get the babel options from the parent for the rollup/babel re-ordering, any chance that changes the semantics of what is applied when? |
No description provided.