Add commonly used modules.

[rwjblue]

Using these modules, all of the blueprints in ember-cli can be written as ES6 (without using Ember.Foo).

[rwjblue]

@stefanpenner - Please review when you have a chance.

[workmanw]

I like having this ability. When I first picked up ember-cli and ES6 it was confusing to me at first that I couldn't do this. But also looking at this manually coded list almost begs for a way to have libraries provide their own exports/import mappings .... but I guess that's the point of this library anyways .... so I've talked my self around in circles.

👍

[rwjblue]

@workmanw - Addons do have the ability to add to the list of known whitelisted modules in their included hook, they can also put files in their addon/ to generate modules namespaced to that addon. Which would allow these same types of imports to work from nearly any addon (either purely ES6 or shimming existing globals/etc).

[workmanw]

I guess I meant at the package level. It was just a notation, I wasn't suggesting any action be taken.

My thought was that Ember uses ES6 internally, then it transpiles back to ES5, then we shim it back to ES6 for the application's consumption. In languages like Java, Python and others the internal package system is assessable outward. I realize that's all a consequence of the fact that ES6 is not natively supported by browsers, but it felt like it'd sure be nice if Ember proper had a mechanism to automatically provide these package definitions as part of the build. BUT again this is a shim library that's it's entire purpose.

[stefanpenner]

@workmanw the reason we don't do this in an automated fashion yet is ember's es6 module exposes the largest API we have exposed to date. Before we expose this, we will need to do a thorough audit an re-organization. As the module system becomes part of the public api.

We hope to get to that point soon, but ^^ is a shim until then.