Babel 6.0 #5015

stefanpenner opened this Issue Oct 30, 2015 · 12 comments


None yet

7 participants

stefanpenner commented Oct 30, 2015 edited

Would like to cut over as soon as possible

npm WARN deprecated babel-core@5.8.33: Babel 5 is no longer being maintained. Upgrade to Babel 6.

  • Migrate ember-cli-babel specific settings out of babel config and into its own ember-cli-babel configuration (with support for older style with a deprecation). This removes one of the "double duties" that the babel config currently takes and should help us traverse the path forward to babel@5 and babel@6 interop. (babel/ember-cli-babel#102)
  • Update ember-cli to require ember-cli-babel for things to function:
    • lib/broccoli/ember-app.js#L1237 - This comment infers something that simply doesn't work anymore. We should likely remove that guard and just throw if we don't detect ember-cli-babel.
  • Update ember-cli-babel to deprecate using the default of "blacklist modules"
    • Change lib/models/addon.js to compile modules. This is used in ember-cli to ensure that we do a two-pass compilation of babel for addons. The first is done by the addon itself, and the second is done by lib/broccoli/ember-app.js#L929.
    • Remove second pass module transpilation in ember-cli's lib/broccoli/ember-app.js.
  • Update ember-cli to use its own specific configuration for modules only babel transpilation instead of utilizing babel config option.
  • Update ember-cli to read and pass through .babelrc in the project and addon root as the default babel options.
@bartocc bartocc referenced this issue Nov 2, 2015

release plan #5028

8 of 11 tasks complete
Turbo87 commented Jun 9, 2016

@stefanpenner I updated the task list above

knownasilya commented Jun 24, 2016 edited

Looks like broccoli-babel-transpiler is holding up ember-cli-babel (and emberjs-build), which is holding up ember-cli-htmlbars-inline-precompile.

Any specific reason that broccoli-babel-transpiler is still an alpha version?

Turbo87 commented Jun 24, 2016

tl;dr I wasn't that familiar with the code when I started and wanted to make sure the Babel 6 port actually worked before releasing this as an official v6.0.0. Since then I've worked with it a little and haven't found any major issues, so we could release it officially soon.


@knownasilya its mostly me dragging my heels on reviewing @Turbo87 wonderful PR's

@tchak tchak referenced this issue in mike-north/ember-lodash Aug 19, 2016

upgrade to use lodash 4.17.2 #22

4 of 9 tasks complete

AFAIK this is blocking general use, or some use of WeakMap in apps that target browsers which would need a polyfill.

stefanpenner commented Aug 19, 2016 edited

@mike-north weak-map comes from core-js, it can be included independently of a babel 6 upgrade. Also, this issue is for enabling babel 6 by default, if your add-on continues to emit ES5 safe code, in the form of de-anonymized AMD. The rest of the eco-system wont notice.

Turbo87 commented Dec 5, 2016 edited

Updated the task list above with a set of more concrete steps

/cc @rwjblue


We will need to port our Globals build infrastructure in ember-data to use babel6 as well. If this is moving forward sooner than the next 2 weeks I will not have any time to work on doing this, but likely can after that.

cc @pangratz @igorT @fivetanley @bmac

rwjblue commented Dec 5, 2016

@runspired - The idea is that each addon specifies its own version. It is extremely unlikely that we can move the entire ecosystem over to babel6 at one specific time. So we plan to allow addons to control their babel version via their existing ember-cli-babel dep's version.

@rwjblue rwjblue referenced this issue Dec 5, 2016

Prevent running babel twice. #6530

5 of 6 tasks complete

@runspired - The idea is that each addon specifies its own version. It is extremely unlikely that we can move the entire ecosystem over to babel6 at one specific time. So we plan to allow addons to control their babel version via their existing ember-cli-babel dep's version.

yup, this.

@homu homu added a commit that referenced this issue Dec 7, 2016
@homu homu Auto merge of #6530 - ember-cli:avoid-two-pass-babel, r=rwjblue
Prevent running babel twice.

We currently transpile the output of all addon's `addon/` trees twice.  Once inside the addon's `treeForAddon` step (this one excludes module transpilation by adding `es6.modules` to babel's blacklist) and the second time in [lib/broccoli/ember-app.js](

This was originally done because we didn't require that addon's include their own preprocessors for JS (mostly due to performance reasons IIRC).  In the time since that decision was made, we have swapped from a few different systems `es6-module-transpiler` -> `esperanto` -> `babel`.  Now that our module transpilation step is using the same thing as we recommend addon's use (`ember-cli-babel`) what we are doing seems pretty whacky.

This PR removes the double processing of addon's `addon/` files through babel, and includes a deprecation message for the scenario that originally prompted the second pass (where an addon didn't include a module transpiling preprocessor).


- [x] Confirm that we have tests that already confirm this is working properly (I believe that our existing nested addon tests cover these changes, but I'd like to confirm).
- [ ] Consider / discuss backporting the deprecation message for addons that do not have a transpiler and are relying on the global processing step.
- [X] Add helpful error if an addon overrides `this.options.babel.compileModules`
- [X] Implement logic to avoid deprecation being added in babel/ember-cli-babel#105.
- [X] Split out `findAddonByName` into a utility method to be shared
- [ ] r?

Addresses parts of #5015
@dustinfarris dustinfarris referenced this issue in dustinfarris/ember-glamor Dec 16, 2016

css template tag #2

mdebbar commented Feb 14, 2017

@stefanpenner @rwjblue do you have an idea when it would be possible to use babel 6? I'm excited to get several perf. improvements for free with babel 6!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment