Ember-cli-typescript: [Bug] Non-public access modifier keywords break lexical scope for property access

[mike-north]

Steps to reproduce:

1. Create a new ember app
2. Install ember-cli-typescript
3. ember g route home
4. Replace your home route's code with something like this

import Route from "@ember/routing/route";

export default class Home extends Route {
  public tool = "ember-cli";
  public model(): any {
    return ["ember", "ember-data", this.get("tool")];
  }
  protected foo() {}
}

What I expected

The presence of a private or protected foo() {} method should not cause other methods in the class to break. I should be free to call foo() from other public, private or protected methods, and see behavior in alignment with the way things work in vanilla TypeScript classes.

What I saw instead

Compilation error on the this.get("tool"):

[ts]
The 'this' context of type 'this' is not assignable to method's 'this' of type 'ComputedPropertyGetters<{ tool: string; model: () => any; foo: () => void; afterModel: (resolvedM...'.
  Type 'Home' is not assignable to type 'ComputedPropertyGetters<{ tool: string; model: () => any; foo: () => void; afterModel: (resolvedM...'.
    Property 'foo' is protected in type 'Home' but public in type 'ComputedPropertyGetters<{ tool: string; model: () => any; foo: () => void; afterModel: (resolvedM...'.

Related: #212 #176

Even if this is a "known limitation", we should track these kinds of things as bugs so they can be triaged and focused on appropriately. Two teams currently trying to adopt Ember+TS were questioning their own sanity for a few days last week, because they found no info (issues/PRs/documentation) that shed light on this.

[chriskrycho]

Added a reference to this to the tracking issue. Also made a mental note that we should start turning questions that come up in Slack into tracking items here if they're not already documented.

[mike-north]

we should start turning questions that come up in Slack into tracking items here if they're not already documented.

💯

Ember Slack isn't a great source of truth for discoverable documentation, due to how quickly messages fall off of the 10K message limit for free accounts

[chriskrycho]

Yep, strongly concur. I've slowly been pushing people to open Discuss or Stack Overflow questions for common issues as well for that reason.

[mike-north]

Is there a particular tag or filter for Discuss/SO that we can embed right at the top of the readme?

Maybe

• https://stackoverflow.com/questions/tagged/ember.js+typescript
• https://discuss.emberjs.com/search?q=typescript

[mike-north]

related: there's some confusion as to where issues should be reported for problems with @types/ember -- should we continue putting that stuff in this repo? perhaps tagged with a particular label?

[chriskrycho]

Great suggestion – mind PR'ing those to the README? We may also be able to contact the moderators on Discuss and get a TypeScript tag added; I think that could be super helpful.

My own take re: @types/ember is that we're best off putting all the discussion in this repo at this point. Having two repos was a really helpful division when we were first building the main Ember types but I think it's outlived its utility at this point. @dfreeman @dwickern @jamescdavis, any thoughts to the contrary?

[mike-north]

Having two repos was a really helpful division when we were first building the main Ember types but I think it's outlived its utility at this point.

I'm going to attempt a solution via different issue templates for different purposes

[chriskrycho]

That sounds like a great solution to me.

[mike-north]

Fix for this (and tests) has been merged into @types/ember master