What's the attitude towards TypeScript from Core team?

Hi, I’m curious what’s the attitude towards TypeScript from Ember Core team. I haven’t found any official statement.

I see that some parts of the Ember are written in TypeScript. I also see some traction towards TypeScript in Ember community.

Is the Ember Core team considering to write Ember in TypeScript and make it first class citizen? Typings at DefinitelyTyped are obsolete with every new version and keeping them up-to-date requires a lot of manual work.

Thank you

1 Like

What I have read is that they are moving to Typescript internally, but that they want to ensure that the API for JS and TS are the same (or as close as is possible). Unlike something like Angular, where the API is significantly different trying to write your app in JS instead of TS. I do think that having TS be a first-class citizen is a goal and that will help the typing definitions. But I wouldn’t be surprised if support for using TS continues to be via the ember-cli-typescript addon rather than integrated directly.

Again, just my interpretation of what I’ve read.

Three points:

  1. We like TypeScript a lot and are happy to be using it to implement an increasing amount of Ember’s internals.

  2. We will not make it mandatory for app authors to use TypeScript. And we have a pretty strong definition of what that would mean – we’re not going to sneak it into being mandatory by designing APIs that are only nice if you’re using TypeScript. Every API needs to be designed for use in Javascript. Runtime consumptions of type information is definitely ruled out.

  3. For app authors who choose TypeScript, we want to keep improving the experience. This falls out naturally from both the increasing amount of TS in Ember’s implementation (which should reduce the need for separately-maintained typings) and our increasing embrace of modern JS features (like native classes), which are easier for TS to analyze.

I’m curious to learn more about this – most of our releases don’t break any public API, so I would have guessed that typings don’t need to change much. Is it because there’s some mechanical work required like bumping version numbers to match?

1 Like

FWIW, I think most of the keeping-things-up-to-date feeling right now is that the community-driven effort to manage the typings has a relatively small number of people on it, and Ember’s API surface is huge, so it’s less to do with Ember itself changing as that—

  • we’re still finding gaps and errors in the existing type coverage
  • sometimes the documentation (which we largely used to figure out what the types of things should be) is simply wrong

That means that there has been an unfortunate but unavoidable (unless or until all of Ember is written in TS and ships its typings with it) amount of “churniness” as we’re improving things rapidly.

1 Like

In the EmberConf keynote, Tom and Yehuda mentioned that a lot of internals are moving to Typescript to help with documentation, expected results, and stability. EmberConf 2018: Opening Keynote by Yehuda Katz by Tom Dale - YouTube

As @ef4 mentioned using Ember in JS will still be a primary experience and Typescript will not be required.

If/when core Ember packages are fully written in Typescript, the type definitions should be able to be shipped with the packages instead of as a separate install which will help with the issue of keeping typing up to date.

TLDR; the JS experience will stay the same and get better, the TS experience will only get better, the core will be more stable.

1 Like

as @chriskrycho pointed out, it’s mostly incomplete API and wrong definitions. Having a wrong definition is most of the time worse than having none.

The one thing that scared me immediately is the comment in Ember definition file which says it’s for v2.8. I have no idea if that’s true or it is just outdated comment.

Because Ember’s API changes are nearly all additive and backwards compatible, you should really read that as 2.8+.

1 Like

As @chriskrycho pointed out, type definition leaks result from lack of documentation that turns out to be wrong. Most of the time, you realize typings are wrong when your own code reaches that point. At this point, open an issue at typed-ember/ember-cli-typescript to note what’s wrong in the first place. Second, go dig into the ember source to find out what is the correct typing and third send a PR to DefinitelyTyped.

What I would like to add regarding the ember internals rewritten in Typescript: This also benefits people who will stick with Javascript as the typings improve the auto-completion in IDEs which will come in handy :+1:

How does it work then for the old apps? If we keep updating typings on DefinitelyTyped with latest API, doesn’t it mean that old Ember apps will get wrong types as some of the API might be available only in the latest version?

Yes, this is a real limitation. However, once we eventually switch to shipping the types directly with Ember, that problem will go away.