This version of the site is now archived. See the next version at v5.chriskrycho.com.

Announcing ember-cli-typescript 1.0.0

Type your apps!

August 08, 2017Filed under Tech#emberjs#typescript#typing-your-emberMarkdown source

I’m extremely pleased to announce the release of ember-cli-typescript 1.0.0! You can get it the same way you do any Ember addon:

$ ember install ember-cli-typescript

For a detailed walkthrough of adding TypeScript to your projects, see:

So what are we shipping today, and what’s on the roadmap?

What’s In 1.0?

This release is intentionally relatively minimal: the goal here is provide stable foundation for building Ember.js applications with TypeScript in the toolchain. This means that in any app you can install the add-on and just start progressively converting your app over to TypeScript. However, we don’t expect to change the way you use the addon at all in the foreseeable future.

I’ll give you fair warning that there is one major challenge you will find as you work with ember-cli-typescript today: the lack of type definitions for most projects, and the limits of the existing type definitions for Ember.js itself. That’s not as bad as it sounds, though:

  1. See the Roadmap below—we’re working on that, and you can help!
  2. I’ve been using TypeScript successfully in the app I work on at my day job for the last nine months or so. While the lack of (good or any) typings has had its frustrations, TypeScript has already added a lot of value for us.

The Roadmap

We have a bunch of things we’re actively working on and which you can expect to land in the next few weeks to months.

1.1: A prepublish build process for addons

The major priority for the 1.1 release is an npm prepublication step to generate JavaScript and typing files from add-ons which are using TypeScript. Currently, addons have to take TypeScript as a full dependency, not a dev dependency, because they currently just ship the .ts files up to npm and they have to be compiled in your app at build time.

We really don’t want to make any app developer who is using your addon download either the TypeScript files or especially the TypeScript compiler if we can avoid it. There are three reasons for this:

  1. The fact that an add-on is developed in TypeScript really shouldn’t affect app developers. If they’re writing a plain-old JavaScript app, the fact that your addon is originally written in TypeScript is irrelevant to them.

  2. TypeScript is large. The v2.4 installation I have in the app I’m working on right now weights 26MB. If I were using four add-ons which required TypeScript, my install cost could easily go up by a hundred megabytes. That’s not always a huge deal on a corporate network, but even where people do have good download speeds, it’s a hit to developer time. Every time someone has to reinstall all the dependencies, those 26MB have to come down again. If TypeScript becomes common, you might suddenly find yourself with addons using 2.4, 2.5, 2.6, etc.; it’s not hard to see that ballooning up the size of your installation in a really non-trivial way: 26MB × n versions of TypeScript = do not want.

  3. The TypeScript compilation step takes time. Addons can do this once and save every consuming app build time. This isn’t the end of the world, but anything we can do to keep build times lower is a real win for developer productivity.

Accordingly the plan is to automatically add a build step which runs the TypeScript compiler on your addon and generates plain-old-JavaScript and the corresponding type definition files (.d.ts) prior to publishing to npm. That way, TypeScript can remain a dev dependency (rather than a full dependency) of each addon, and not be installed alongside the addon for consumers. Just-JavaScript consumers can just consume the normal JavaScript generated by the build. TypeScript consumers will get the full benefits of the types via the generated typing files.

This should hopefully land by late August or early September. Fingers crossed.

Community-driven work on typings

The process of getting type definitions in place for all of Ember.js and its ecosystem is way, way too big for any one person or even a small handful of people to manage alone. This is something we’re going to take on as a community.

New typings for Ember.js itself

We’re actively working on type definitions for Ember which will give us actually-useful-and-correct type checking for Ember’s custom object model. Today, if you use Ember.get or Ember.set, you get no help from the type system. When we finish, those will be type-checked by the compiler and will error if you try to assign the wrong values!

Importantly, the typings we’re shipping will be backwards compatible with the existing Ember API, but will also include support for the RFC #176 JavaScript Modules API. TypeScript’s module definition system will let us support both in parallel, and we will. Backwards compatibility and stability without stagnation are things we value for this addon just as much as the rest of the Ember.js ecosystem does.

This effort, led by Derek Wickern (@dwickern), is ongoing in the typed-ember/ember-typings repository. (If you’re wondering why we’re not just doing it in the DefinitelyTyped repository, see below.) We probably won’t be able to get to 100% of everything the Ember Object model does—Ember’s custom object model is incredibly sophisticated, and TypeScript actually still can’t totally express it—but Derek already has most of it working. This will be a huge step forward.

To be clear, we’re not forking the way you get types. We’ll upstream all of this work to DefinitelyTyped as soon as we have them working, but the DefinitelyTyped repo is huge and very busy; it’s not a great place to do this kind of substantial rework of existing types. And we really don’t need to have all the other type definitions DefinitelyTyped supplies in our way as we’re working, either. Having a separate repo gives us a place we can work on types, try them out as a community, etc. before creating PRs on DefinitelyTyped and publishing them officially.

Addon typings

We need to get type definitions in place for the addons in the ecosystem! That way when you’re using, say, ember-test-selectors, you’ll get an error if you try to use the functions it provides incorrectly. Right now, every addon out there is missing types entirely, so everything gets treated as taking the useless any type.

In a week or so, I’ll have a blog post with a fleshed-out quest issue for tackling it in detail, but here’s the short version: we’re going to try to get type definitions for all the top addons in the ecosystem so that it’s easy to use TypeScript in your Ember.js app. That blog post and quest issue will explain how to write good typings, and also how to contribute them to a project which may or may not be interested in using TypeScript itself.