Update README for ember-cli-babel@6

[rwjblue]

High Level items:

• We use babel-preset-env to control transpilation.
• The project.targets property (which comes from config/targets.js`) is used to pass babel-preset-env's list of targets.
• All options added in options.babel are passed on to babel-preset-env

New public API's:

• transpileTree (from Expose a public mechanism to transpile a tree. #126)
• isPluginRequired (from 16ed336 and Fix issues with isPluginRequired. #117)
• We allow options.babel6 for backwards compat with older ember-cli versions (which were sharing the projects babel config from ember-cli-build.js between both the app/addon itself and ember-cli's internal transpilation)

Plugin ordering:

1. plugins in options.babel.plugins
2. modules plugin if options['ember-cli-babel'].compileModules is true
3. plugins from `babel-preset-env
4. plugins in options.babel.postTransformPlugins

[rwjblue]

I would love help from someone, if they have time to start working on this...

[buschtoens]

The current README contains incorrect code:

treeForAddon(tree) {
  let addon = this.addons.find(addon => addon.name === 'ember-cli-babel'); // find your babel addon

  let options = addon.buildBabelOptions({
    'ember-cli-babel' // <--- ### INCORRECT ###
  })

  return addon.transpileTree(tree, {
    'babel': {
      // any babel specific options
     },

    'ember-cli-babel': {
      // any ember-cli-babel options
    }
  });
}

I don't really understand what you originally try to achieve here and where to put options. It seems like this could be used to retrieve the options of the parent addon / app?

[rwjblue]

The let options = statement should be removed (from this section at least. buildBabelOptions accepts the same as the second arg to transpileTree (just below in the snippet). The idea was to show how you might build your own options programmatically (perhaps you need to conditionally add plugins or something), and then show that just calling .translileTree with the normal input options would be the same as building them manually and passing them in.

[buschtoens]

Shouldn't the _super method be called as well?

We're having some trouble with in-repo-addons over on Slack.

I created a demo app here: https://github.com/buschtoens/in-repo-addon-demo

/* eslint-env node */
'use strict';

module.exports = {
  name: 'foo-addon',

  isDevelopingAddon: function() {
    return true;
  },

  treeForAddon(tree) {
    const addon = this.addons.find(addon => addon.name === 'ember-cli-babel');

    return addon.transpileTree(tree);
  }
};

[buschtoens]

When you turn on the custom treeForAddon hook, the final vendor.js looks a bit different, resulting in this error:

Error: Could not find module `foo-addon/components/foo-component/component` imported from `in-repo-addon-demo/components/foo-component`
    at missingModule (loader.js:232)
    at findModule (loader.js:243)
    at Module.findDeps (loader.js:173)
    at findModule (loader.js:247)
    at requireModule (loader.js:26)
    at Class._extractDefaultExport (index.js:392)
    at Class.resolveOther (index.js:108)
    at Class.superWrapper [as resolveOther] (ember.debug.js:42849)
    at Class.resolve (ember.debug.js:7201)
    at resolve (ember.debug.js:4590)

Here's a diff: https://gist.github.com/buschtoens/20a8a96b9c5ac07b73db0ef96abf08e3/revisions

[rwjblue]

#154 did a significant pass to refactor the README. I believe the snippets have been simplified (and are now valid), and all of the options we support are documented.

Closing...