Support for Ember JavaScript Modules API

[kratiahuja]

First off, thank you very much for all your hard work here. Really excited to see this reaching the 1.0.0 line. 🎉

I believe Ember is going to switch to use the JavaScript Modules API (that is Ember packages will be modules instead off a global namespace + destructuring). I believe the shim support (with ember-cli-babel 6.6.0 and above) for this is already being landed in Ember 2.16 (API docs are being changed to point to the new usage, Ember CLI blueprints are already being updated etc). There is also a JSON map today for making it easier to map: https://github.com/ember-cli/ember-rfc176-data

With this, I believe the type definitions for Ember need to be redefined (with multiple namespaces), otherwise it will break apps wanting to use this addon. Is there a plan to have some parity release with 1.0.0 (example 1.0.0 is only supported for apps using below Ember CLI 2.15)? Or will 1.0.0 support the new modules API as well?

[chriskrycho]

Great call-outs.

1. We're actively working on it—I'll have a blog post up tomorrow or Wednesday talking about that plan, but for a preview, you can watch typed-ember/ember-typings, where we're (a) building an updated, well-typed set of typings for Ember using the latest TS bits and (b) going to have support for the new modules API.

2. So, about that new modules API: my plan is to track what Ember itself is doing: starting by landing re-export shims around the existing (global) type declarations. That way, the transition will be fully backwards compatible for consumers of the typings. (TS does allow us to re-export that way, so that's what we'll be doing.) As Ember moves from just shims to actually shipping the packages, not just shims, we'll probably do likewise (though we'll need to continue to think about how to maintain backward compatibility there).

[chriskrycho]

Also, dupe of #39. Going to close this in favor of that one. Also going to update that one once I have those blog posts ready.

[kratiahuja]

@chriskrycho Thanks for super detailed response. Happy to see we are thinking in that direction as well.

Curious to understand the following:

1. Why are we moving away from having the type definition in DefinitelyTyped to a different repo/organization?

My team is eagerly looking to use this and we would be more than willing to lend a helping hand in shipping things for 1.0.0. Is there a roadmap that you could share in your blog post/issue in this repo that we can contribute to?

[chriskrycho]

@kratiahuja roadmap is going to be there, yep! I'm just swamped with a couple other things and haven't had a chance to write it up yet. One big part of the roadmap is going to be getting typings in place for the rest of the ecosystem, on top of Ember itself. Probably have it up tomorrow or Wednesday.

As for DT: we are planning to push everything back to DT. But because we're rewriting all the definitions to take advantage of new features from the TS 2.x series, and there's a lot to do, it's a lot easier to coordinate by just having a small repo where we can work together on it. You're more than welcome to pitch in there! DT is a rough place to try this kind of thing: it's a high-traffic, many-project repo. Having a small one of our own also gives us a place where we can have early versions of it for people to try and find gaps, edge cases, etc. so we can tighten it up and ship it solidly before we submit a very large PR to DT with all these changes (can't really do it incrementally).

[theroncross]

Is there a clean way to reference ember-typings (instead of DT) for testing?

[chriskrycho]

@theroncross You should be able to npm install or yarn from the actual repo and then just include it in the paths mapping in compilerOptions.