Ember-cli-typescript: (doc): What's currently not yet TypeScript friendly

[mike-north]

I'm excited every time a commit gets merged into this addon, and can't wait until we can use TypeScript in Ember user-land code to a higher degree!

One thing that may be helpful is some clarity around what can and can't be done, relative to the advised TypeScript best practices. Here's a start

Not (yet) supported:

Extending from framework entities using class syntax

export default MyComponent extends Ember.Component {
}

Type safety when invoking actions

actions: {
   turnWheel(degrees: number) {
      ...
   }
}

```hbs

```js
// TypeScript compiler won't detect this type mismatch
this.send('turnWheel', 'ALSO-NOT-A-NUMBER');

Type safety when invoking KVO compliant accessors or mutators

Ember.Object.extend({
  urls: <string[]> null,
  port: 4200,
  init() {
     this._super(...arguments);
     this.set('urls', []);
  },
  foo() {
    // TypeScript won't detect these type mismatches
    this.get('urls').addObject(51);
    this.set('port', 3000);
  }
});

[chriskrycho]

@mike-north this is _awesome_. If you turn this directly into a PR for the README, I'll merge it. We can expand on it over time. I'm going to update the README with info on working with add-ons early this afternoon and we should be able to do a 0.4.0 release which will make this usable for a lot of people.

[chriskrycho]

Update: I've added the above to #32! Should ship soonish. More comments/docs very welcome. I'm squeezing this in outside work.

[mike-north]

Currently building some material on this (over the next few days). Will update this with any other untyped embery things as I find them

[chriskrycho]

That'll be fantastic. Much obliged!

[pixelhandler]

@mike-north Looks like the README includes the 'not yet' section now, https://github.com/emberwatch/ember-cli-typescript/blob/master/README.md#not-yet-supported perhaps this issue can be closed.

[chriskrycho]

@pixelhandler my intent based on @mike-north's response that if he is going to add more details—whether as comments here or as PRs directly against master—we can leave this open as a "tracking" issue until we're satisfied that we're covering everything.

[NLincoln]

I've noticed that module resolution is a bit messed up wrt addons. For example,

import computed from 'ember-macro-helpers/computed';

will give TS2307: Cannot find module 'ember-macro-helpers/computed'.

[mike-north]

@NLincoln thanks, this certainly fits into this category, and I'm seeing it too. Ember addons need to be mapped in some way via the tsconfig file

I believe this has something to do with
ember-macro-helpers/computed
being found in a file like
ember-macro-helpers/addon/computed
and the typerscript compiler has no knowledge of this convention

[rwjblue]

Confirm. FWIW, we address this in module unification. The import path you use in the app will actually match a file on disk (using the normal node module resolution algorithm).

[chriskrycho]

The module unification approach will be a nice win. In the meantime, if the resolution path is standardized (in general, I'm still quite new to the add-on side of things, so someone should comment one way or the other!) we should be able to update the tsconfig values accordingly—e.g. by setting the paths to include something like "*/*": "node_modules/*/addon/*" (though note that that's totally untested and almost certainly very wrong; the point is that you can do those kinds of mappings). It depends on just how conventional the layout of the exports of most add-ons actually is.

[chriskrycho]

Closing this as we’ve either fixed it via typings work or gotten it into the docs in some shape or form. Thanks, everyone!