[BUGFIX lts] Fix transpilation issues (e.g. _createSuper is not a function) when used with Babel 7.9.0+.#18831
[BUGFIX lts] Fix transpilation issues (e.g. _createSuper is not a function) when used with Babel 7.9.0+.#18831
_createSuper is not a function) when used with Babel 7.9.0+.#18831Conversation
|
Confirmed failure: |
Due to the way Ember itself is compiled, we have custom versions of the `@babel/helpers` that we inline into the IIFE that contains Ember. This is obviously pretty unideal (largely because it forces us to be misaligned with Babel and therefore brittle to reasonable changes that they make). These helpers have been pretty stable for quite a while, but recently Babel 7.9.0 introduced a couple of new helpers: * `createSuper` allows subclassing from native classes, even when partially transpiled). * `createForOfIteratorHelperLoose` Versions of `ember-source` prior to 3.13 fully transpiled with the Babel version in `emberjs/ember.js`s _own_ `yarn.lock` at publish time. The build process was significantly changed in `ember-source@3.13.0` so that `ember-source` would behave just like a normal addon. This was a **huge** improvement!! Unfortunately, those changes also made us vulnerable to changes made to Babel (new helpers added). We **must** resolve that issue (likely by removing these custom external helpers in favor of using `includeExternalHelpers` from `ember-cli-babel`), but in the meantime this commit adds the required helpers which should fix the reported issue in supported Ember versions.
rwjblue
changed the title
_createSuper is not a function) when used with Babel 7.9.0+.
|
FYI - These changes will need to be backported for 3.16 (affected LTS), 3.17 (current release), and 3.18 (current beta). |
rwjblue
changed the title
_createSuper is not a function) when used with Babel 7.9.0+._createSuper is not a function) when used with Babel 7.9.0+.
|
to avoid such issues in the future would it make sense for use to switch to |
@Turbo87 - It would not have made a difference in this case. The drift is from ember-cli-babel itself, I suppose we could pin it with |
|
FYI - I've just queued up the CI jobs that will publish 3.17.1 and 3.16.4 (the next beta should be published tomorrow). To follow along:
If either of these are red, it means the release didn't publish so please ping me and let me know! |
|
v3.17.1 is published with this fix (should resolve things for folks generating new apps), but I made a mistake when pulling back these changes for 3.16 (just forgot to include the commits when cherry-picking other fixes 🤦♂) and v3.16.4 does not include this fix. I have kicked off a publishing of v3.16.5 (definitely with these changes) and it is working its way through CI now: https://travis-ci.org/github/emberjs/ember.js/builds/665843150 |
|
@rwjblue by any chance has this been upstreamed to beta yet? |
|
@jherdman - It is in |
|
Much, love! Thank you so much for all that you do. |
|
@rwjblue do you know when will be published to npm? |
|
@poplevente - v3.18.0-beta.3 was published yesterday (roughly 17 hours ago). |
|
@rwjblue i don't see that on npmjs |
|
@rwjblue i mean update ember-cli |
|
@rwjblue our problem is that we have a project which was running with ember-source@3.13 |
|
3.13 is unsupported (contains loads of bugs fixed in more recent versions), 3.12 works well and is a supported LTS that is unaffected by the issue this PR fixes (though it does not contain all of the octane features, e.g. tracked). As far as I see it, you have a few options:
|
|
@rwjblue awesome thanks! |
…3.16.0` This should hopefully avoid emberjs/ember.js#18831
| function arrayLikeToArray(arr, len) { | ||
| if (len == null || len > arr.length) len = arr.length; | ||
|
|
||
| let arr2 = new Array(len); | ||
| for (let i = 0; i < len; i++) { | ||
| arr2[i] = arr[i]; | ||
| } | ||
|
|
||
| return arr2; | ||
| } | ||
|
|
||
| /* | ||
| Does not differ from default implementation. | ||
| */ | ||
| function unsupportedIterableToArray(o, minLen) { |
There was a problem hiding this comment.
@rwjblue any reason why these 2 functions are not exported?
I am upgrading ember version for few of my old repos and CI fails with TypeError: (0 , _emberBabel.arrayLikeToArray) is not a function.
We added a patch to export these functions, and it resolved the issue.
There was a problem hiding this comment.
These were not exported because they were never intended to be public.
This entire file is gone on main since #20873 and unused even longer.
What version of Ember did you upgrade to? I suggest you check https://github.com/ember-cli/ember-new-output to make sure your package.json has updated all the required packages.
8 participants
Due to the way Ember itself is compiled, we have custom versions of the
@babel/helpersthat we inline into the IIFE that contains Ember. This is obviously pretty unideal (largely because it forces us to be misaligned with Babel and therefore brittle to reasonable changes that they make).These helpers have been pretty stable for quite a while, but recently Babel 7.9.0 introduced a couple of new helpers:
createSuperallows subclassing from native classes, even when partially transpiled).createForOfIteratorHelperLooseVersions of
ember-sourceprior to 3.13 fully transpiled with the Babel version inemberjs/ember.jss ownyarn.lockat publish time. The build process was significantly changed inember-source@3.13.0so thatember-sourcewould behave just like a normal addon. This was a huge improvement!! Unfortunately, those changes also made us vulnerable to changes made to Babel (new helpers added).We must resolve that issue (likely by removing these custom external helpers in favor of using
includeExternalHelpersfromember-cli-babel), but in the meantime this commit adds the required helpers which should fix the reported issue in supported Ember versions.Fixes #18827