--- Title: Announcing ember-cli-typescript 1.0.0 Subtitle: Type your apps! Tags: [typing-your-ember, typescript, emberjs] Category: Tech Date: 2017-08-08 09:00 Summary: > A stable foundation for building Ember.js apps with TypeScript, and a roadmap toward a flourishing, TypeScript-friendly ecosystem in the future! --- I'm extremely pleased to announce the release of [ember-cli-typescript 1.0.0][1.0.0-release]! You can get it the same way you do *any* Ember addon: ```sh $ ember install ember-cli-typescript ``` [1.0.0-release]: https://github.com/typed-ember/ember-cli-typescript/releases/tag/v1.0.0 For a detailed walkthrough of adding TypeScript to your projects, see: - [Typing Your Ember, Part 1: Set your Ember.js project up to use TypeScript.][part-1] - [Typing Your Ember, Part 2: Adding TypeScript to an existing Ember.js project.][part-2] [part-1]: http://v4.chriskrycho.com/2017/typing-your-ember-part-1.html [part-2]: http://v4.chriskrycho.com/2017/typing-your-ember-part-2.html 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][part-3]. However, we don't expect to change the way you *use* the addon at all in the foreseeable future. [part-3]: http://v4.chriskrycho.com/2017/typing-your-ember-part-3.html 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**][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][ddd-ts]. [roadmap]: #the-roadmap [ddd-ts]: https://www.dailydrip.com/blog/domain-driven-design-and-typed-functional-programming-in-typescript ## 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][1.1] - [Community-driven work on typings][typings] [1.1]: #1-1-a-prepublish-build-process-for-addons [typings]: #community-driven-work-on-typings ### 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][rfc-176]. 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. [rfc-176]: https://github.com/emberjs/rfcs/pull/176 This effort, led by Derek Wickern ([\@dwickern]), is ongoing in the [typed-ember/ember-typings][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][ts-limit] *totally* express it---but Derek already has most of it working. This will be a *huge* step forward. [\@dwickern]: https://github.com/dwickern [ts-limit]: https://github.com/Microsoft/TypeScript/issues/16699 [ember-typings]: https://github.com/typed-ember/ember-typings 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. [ember-test-selectors]: https://github.com/simplabs/ember-test-selectors 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. [quest issue]: https://github.com/typed-ember/ember-cli-typescript/issues/48