incompatible with ember-cli@2.15

[gossi]

The addon unfortunately has problems with ember-cli@2.15. My setup:

$ ember -v
ember-cli: 2.15.1
node: 8.6.0
os: darwin x64

Steps to reproduce:

ember new ember-test-ts
cd ember-test-ts
ember install ember-cli-typescript
ember g route application

// routes/application.js

import Ember from 'ember';
import TestClass from 'ember-test-ts/lib/TestClass';

// ...

// lib/TestClass.ts

export default class TestClass {
	private bar;
	constructor(foo = {}) {
		this.bar = foo.bar;
	}
}

and then run ember serve which leads to this error:

Uncaught Error: Could not find module `ember-test-ts/lib/TestClass` imported from `ember-test-ts/routes/application`

It is independent whether TS version 2.4 resp. 2.5 is used, I tried both.

What's interessting, is when running with BROCCOLI_DEBUG=ember-cli-typescript:* ember serve the DEBUG/ember-cli-typescript:1 directory is empty.

[chriskrycho]

Thank you very much for the report! I'll take a look (or maybe someone else enterprising will) as soon as I'm able. A heads-up, though: I'm moving across the country in the next week so it's likely I'll be a bit slow to get back to it. It is a high priority, however.

[chriskrycho]

@gossi have you tried this with Ember CLI 2.16? I spun up a new app today with it and it worked without issue. 🤔

[gossi]

Yup, 2 days after I tried with 2.15 version 2.16 of ember was released and I tried with ember-cli-typescript which didn't worked for me, but I will retry.

[chriskrycho]

Heh, perhaps obvious but worth confirming—can you dump your tsconfig.json in here, and confirm that you are indeed using something quite specifically at the path <path to the app>/lib/TestClass.ts? I have a suspicion which I can check later which might be what you're seeing here.

[gossi]

I gave it another try a few seconds ago. I repeated the same steps I described above.

$ ember -v
ember-cli: 2.16.2
node: 8.9.0
os: darwin x64

with ember-cli-typescript@1.0.4 and it worked. I would be tempted to update my app to TypeScript, though I'm a bit afraid how update-aware this addon is.

[chriskrycho]

@gossi I'm not sure what you mean by "how update aware this addon is." I'm happy to clarify if there's any confusion or concern there.

I can say that we're using this at Olo and I'll continue to update it and work on it regularly—we try to keep up with Ember and TypeScript releases, and while that sometimes slips a month or two, it's rarely more than that. For context, I'm planning to upgrade our main Ember.js app from 2.14 to 2.17 the last week of November, and my goal is for us to be on minor releases a week after they come out from that point forward. So if/when we hit problems, we'll see them. The blocker for me, as for most open-source maintainers, is that this is a pretty small part of my job and I have to ship features!

Let me know if there are specific blockers I can help with for you!

[gossi]

Yes, it's going that direction. I'm on ember for like 2 years now (or a bit more). The app I'm currently working on is now one year old. I have taken every ember update since that time, because I was happy about newly introduced features here. Although the ember team says, updates happen seemlessly, they never do. After each upgrade I had to to some fixes, often in combination with some of the addons I installed. So far I could fix everything within reasonable time. Though if I now rely on typescript and the addon stops working after upgrading ember, well I'm pretty much fucked 😀 and for sure I do not want to run into that situation.
I was wondering if that could be "coped" in advance or some other actions that would help in that situation?

[chriskrycho]

@gossi so, here's my plan for making that less of/not an issue:

• We already have this addon building against Ember beta and canary releases, and that didn't flag any issues with e.g. 2.15 (nor did my own apps and testing)—so if you can identify what specifically broke we can get it in test cases that are part of this to help make sure there's no regression there in the future. Sadly, apart from a specific reproduction, I can't do much better than that. ¯\_(ツ)_/¯

• Between now and the end of the year, I'm going to be setting up CI on our app (now ~30k lines of TS, will be ~35–40k by end of year) to run against beta and canary and report any breakages to us on every commit to our mainline branch; that will presumably also be useful in flagging up any issues. If I see issues on beta especially, and they're related to TS specifically, I'll be prioritizing fixing them, not least because I want them for our app(s).

I think that should give you most or all of the stability that you need (and it's really the best anyone can do here, I think).

If you do start running your app with TS, doing the same as I will with beta/canary via ember-try could be really helpful in surfacing any issues. As far as I know, my app is currently the largest ember-cli-typescript consumer in the world right now, so having more data would be super helpful in that regard.

[chriskrycho]

(Note: I'm closing this but not locking it, as I think the issue is strictly speaking "resolved" but I'm happy for discussion to continue.)

[gossi]

Yup, this issue is closed and you already explained what I wanted to know, thanks a lot for that and your effort behind. Maybe this also should be documented somewhere :)

[chriskrycho]

Great suggestion. I'll add it to the README!