1. Execute on Our Priorities

All of us want this to happen. It’s not yet clear what all of our priorities will be in our jobs over the back half of 2019—but if we can, we’d like to see those efforts across the line.

The TypeScript team has eased one of our heavy burdens, by investing in performance monitoring infrastructure over the course of this year and paying close attention to how their changes affect us as well as other TypeScript consumers. We’re deeply appreciative! But there’s still a lot of work to be done that just needs time to actually do the work—reducing churn in type definitions, building type-checked templates, and improving our documentation.

None of those are insurmountable by any stretch. But they’d also be far likelier to happen if they were concretely identified as priorities for Ember as a whole, and we had commitment from the community to help!

To briefly summarize those priorities again:

• We need to make it so that consumers of our type definitions do not face breakage from updates to Ember’s types or TypeScript definitions. We already worked out a basic strategy to solve this problem, and I’ve done further exploration to validate that with key stakeholders of large apps (both TypeScript users and apps which want to use TypeScript) and core Ember contributors… but none of us have had time since EmberConf to write out the strategy as a Typed Ember RFC, much less to do the actual implementation work.

• We need to make templates type-aware and type-safe. As fantastic as the experience of writing Glimmer components is—and I genuinely do love it!—it’ll be an order of magnitude better when you get autocomplete from your editor as soon as you type <SomeComponent @… and see the names of the valid arguments to a SomeComponent and the types of things you can pass to them. Everyone who has used TSX in a well-typed React app knows just how good this can be. We can make the experience equally great in Ember, while maintaining the authoring and performance advantages of separate templates. Again: we know how to do this (and the TypeScript team is also working on things which may make it even better for us). We just need the time allocated to take the work from prototype to ready-for-real-world-use.

• We need to dramatically expand the documentation we provide. Right now, ember-cli-typescript provides a minimal (and very useful!) set of docs. It’s enough to get you started, and if you’re already comfortable with TypeScript you’ll do all right. However, we’d love to provide helpful guides that show people not just the mechanics of using TypeScript with an Ember app, but best practices and techniques and the happy path. There’s a world of difference between being able to run ember install ember-cli-typescript successfully and being able to author an app or addon in TypeScript successfully, and we need to bridge that gap for successful ecosystem-wide adoption!

2. Type the Ecosystem

We also need to do the work—and this simply cannot be done solely by the handful of us that make up the core team—to get types in place for the whole of the Ember ecosystem. Two years ago, I started drafting a blog post outlining a quest to type the ecosystem. I rewrote a good chunk of it last year. I even began working on a draft of the quest in our repository in 2018! But we haven’t actually done it, and while a handful of important addons do now have types, (a) most still don’t, and (b) many of those which do have type definitions could use further iteration to tighten them up to make them more reliable or more useful.

I hope to actually open that quest sometime during the third quarter of this year. If things go as I hope, I will be doing some of that work myself, and I will be building documentation and training materials for others so they can see how to do it, and I will be available for code reviews on conversion efforts. I cannot guarantee that by any stretch—but it is my fervent hope, and there is very good reason to think it may actually come to pass!

In many ways, this also hinges on our ability to provide a good story for reducing churn in type definitions. Just as it’s important that we make Ember’s own types stable for consumers, it’s also important that we help addon developers provide the same kinds of guarantees for their consumers. The entire Ember community takes SemVer seriously, and that means the tools have to support that.

3. Define Ember’s TypeScript Story

If we manage to execute on all the priorities outlined above, then there’s one last step for making TypeScript an official part of Ember’s story: an RFC defining exactly how Ember can officially support TypeScript—including two major commitments:

• shipping its own type definitions, with a well-considered approach to SemVer and TypeScript
• considering TypeScript a peer to JavaScript in API design decisions

I have an basic frame in mind for how we tackle both of those. The first is by far the more important of the two; the latter is already happening in an ad hoc way and merely requires the former before it can be formalized. But getting to the point where Ember can ship its own type definitions while upholding its semantic versioning commitments and taking advantage of the advances always happening with TypeScript itself is a large and non-trivial task.

It means a substantial amount of work within the Ember codebase. It means building new tooling for Ember’s core development process—so that the experience of working on Ember itself can remain ever-more productive even as we make sure that the types published for consumers are reliable, accurate, and stable. It means investing in both further education of the community and more static analysis tooling, to make sure that breaking type-level changes are not introduced accidentally.

These efforts are worth the investment they will require, but they are serious efforts.