Generators

We’ve now added support for generating all standard Ember items as TypeScript files instead of JavaScript files. So now when you run ember generate component user-profile for example, you’ll get user-profile.ts, user-profile-test.ts, and user-profile.hbs. For most files, this is just a nicety—just two files you don’t have to rename!—but in the case of services, controllers, and Ember Data models, adapters, and serializers it will actually make a really big difference in your experience of using TypeScript in your app or addon.¹

Those generators are mostly identical with ones in Ember and Ember Data, just with .ts instead of .js for the extension. The only changes we have made are: (a) we’ve tweaked them to use classes where possible, and (b) we have customized the controller, service, and Ember Data model, adapter, and serializer generators so you get the most mileage out of TypeScript for the least effort we can manage today. So when you do ember generate service session, this is what you’ll see:

import Service from "@ember/service";

export default class Session extends Service.extend({
  // anything which *must* be merged on the prototype
}) {
  // normal class definition
}

// DO NOT DELETE: this is how TypeScript knows how to look up your services.
declare module "ember" {
  interface ServiceRegistry {
    session: Session;
  }
}

Courtesy of these generators, you can now write almost exactly what you’d write in vanilla Ember and get full support for autocompletion of properties and methods on the Session service, as well as type-checking for how you use those. Service and controller injections just require you to explicitly name the service or controller being injected:

import Component from "@ember/component";
import { inject as service } from "@ember/service";

export default class UserProfile extends Component {
  session = service("session");
  // note the string ^ naming the service explicitly
}

So, for example, if your session service had a login method on it:

import Service from "@ember/service";
import RSVP from "rsvp";

export default class Session extends Service {
  login(email: string, password: string): RSVP.Promise<string> {
    // some API call to log in
  }
}

// DO NOT DELETE: this is how TypeScript knows how to look up your services.
declare module "ember" {
  interface ServiceRegistry {
    session: Session;
  }
}

Then anywhere you injected and used it, you’ll get auto-complete suggestions and type checking:

(You’ll see the same kinds of things in other editors, from Vim to IntelliJ IDEA. Visual Studio Code is just my current editor of choice.)

Addon development

As promised with the 1.0 release, 1.1 (though arriving much later than I hoped it would) includes support for developing addons with TypeScript.

Strictly speaking, of course, you could always develop addons using TypeScript, but there were two problems with it: (1) dependency management and (2) manual work required to deal with the dependency management problems.

Incremental compilation

Last but not least, we’ve managed—mostly through the hard work of both Dan Freeman (@dfreeman) and Derek Wickern (@dwickern—to get support for TypeScript’s --watch mode integrated.⁴ What this means in practice is: way faster iteration as you work.

Previously, every time you triggered any change in your app (even if it didn’t involve any TypeScript files at all), the TypeScript compiler would recompile all the TypeScript files in your application. We didn’t initially have a good way to make TypeScript and Broccoli (and therefore Ember CLI) communicate clearly about what had changed. Now, courtesy of Dan and Derek’s hard work (and my cheerleading, testing, and fixing a few corner pieces along the way), we do! So when you change a .hbs file or a .js file… the TypeScript compiler won’t do anything. And when you change a TypeScript file, the TypeScript compiler will only recompile that file.

On my own app (~35,000 lines of TypeScript across ~700 files), that’s the difference between rebuilds involving TypeScript taking 15–20 seconds and their taking 1–2 seconds. Literally an order of magnitude faster! Over the course of a day of development, that saves a huge amount of time.

The way we did it also solved an incredibly annoying problem we had in the previous pass: any change to your app was triggering tsc to rebuild the entire TypeScript tree of your app, even if you didn’t so much as look at .ts file. This was particularly annoying when combined with the long rebuild times: change a CSS file and wait for your TypeScript files to rebuild? Ugh. But not anymore!

Credit and Thanks

Massive credit goes to Dan Freeman (@dfreeman) and Derek Wickern (@dwickern), who did most of the heavy lifting on the internals for this release, and together unlocked both incremental compilation and addon support. Derek also did the lion’s share of the work on writing the types for Ember and Ember Data.

Thanks to Maarten Veenstra (@maerten) for the original inspiration (and a spike last summer) for using a type registry, and to Mike North (@mike-north) for some discussion and planning around the idea late in 2017. I may have implemented them, but the ideas came from the community!

Thanks to Frank Tan (@tansongyang) for doing a lot of the work on porting the generators from the Ember and Ember Data repositories to ember-cli-typescript, as well as converting them to TypeScript and to use the new formats. He also contributed the type definitions for the new (RFC #232) QUnit testing API.

Thanks to everyone who contributed to ember-cli-typescript or the Ember typings in any way since we released 1.0.0:

• ember-cli-typescript contributors (note that I intentionally include here everyone who opened issues on the repository: that is not a small thing and has helped us immensely):

  • Bryan Crotaz (@BryanCrotaz)
  • Daniel Gratzl (@danielgratzl)
  • Guangda Zhang (@inkless)
  • @guangda-prosperworks
  • Krati Ahuja (@kratiahuja)
  • Martin Feckie (@mfeckie)
  • Nikos Katsikanis (@QuantumInformation)
  • Per Lundberg (@perlun)
  • Prabhakar Poudel (@Prabhakar-Poudel)
  • Ryan LaBouve (@ryanlabouve)
  • Simon Ihmig (@simonihmig)
  • Theron Cross (@theroncross)
  • Thomas Gossman (@gossi)
  • Vince Cipriani (@vcipriani)

• Ember typings contributors:

  • Adnan Chowdhury (@bttf)
  • Derek Wickern (@dwickern)
  • Frank Tan (@tansongyang)
  • Guangda Zhang (@inkless)
  • Ignacio Bona Piedrabuena (@igbopie)
  • Leonard Thieu @leonard-thieu
  • Logan Tegman @ltegman
  • Martin Feckie (@mfeckie)
  • Mike North (@mike-north)
  • Nathan Jacobson (@natecj)
  • Per Lundberg (@perlun)
  • Robin Ward (@eviltrout)

Thanks to Rob Jackson (@rwjblue) and Tobias Bieniek (@Turbo87 on GitHub, @tbieniek in the Ember Slack) for answering tons of questions and putting up with regular pestering about Ember CLI.

And last but not least, thanks to everyone who’s popped into #topic-typescript on the Ember Community Slack with questions, comments, problem reports, and the occasional word of encouragement. It really does help.