Wednesday, April 24, 2024
HomeJavaScriptSecure TypeScript Sorts in Ember 5.1

Secure TypeScript Sorts in Ember 5.1

The headlining function of Ember 5.1 is secure TypeScript assist! 🎉 The framework now publishes TypeScript varieties constructed from Ember’s personal supply code, with Ember’s sturdy Semantic Versioning dedication baked in—bringing advantages for each TypeScript and JavaScript customers. This devoted weblog put up walks by all the small print.

Getting began

Each JavaScript and TypeScript builders can profit from utilizing these new kind definitions. In case you are JavaScript developer, this can make computerized imports, in-editor framework documentation, and different options work significantly better for you in your Ember app or addon. In case you are a TypeScript consumer, you’re going to get all of these advantages in addition to the sturdy kind security ensures and refactoring capabilities you’re used to.


In your app/app.js, add this single doc remark to the underside of the file:

 * @typedef {import('ember-source/varieties')} EmberTypes

That is all that’s essential to unlock autocomplete and in-editor documentation for all of the @ember/* packages which ship with Ember with no different adjustment required! Any editor configured to make use of the TypeScript language server for JavaScript assist will “simply work” when you make this modification—together with VS Code, the place this works in a default set up.


Utilizing the secure varieties in a brand new TypeScript initiatives is much like setting it up for JavaScript, however has a couple of extra steps. To offer most backward compatibility with the remainder of the Ember ecosystem, the default TypeScript blueprint nonetheless makes use of the @varieties packages, and configures these packages to make use of Array prototype extensions. Each of those are incompatible with the secure varieties, so we have to take away them! Sooner or later, as soon as we are able to swap to defaulting to utilizing the secure varieties within the default blueprint, these additional steps is not going to be mandatory.

(For particulars on migrating present Ember TypeScript initiatives, see the Migration Information under as effectively.)

First, in varieties/<your-app>/index.d.ts, you’ll seemingly have one thing like this:

import Ember from 'ember';

declare world {
  // Prevents ESLint from "fixing" this by way of its auto-fix to show it into a sort
  // alias (e.g. after operating any Ember CLI generator)
  // eslint-disable-next-line @typescript-eslint/no-empty-interface
  interface Array<T> extends Ember.ArrayPrototypeExtensions<T> {}
  // interface Perform extends Ember.FunctionPrototypeExtensions {}

export {};

You’ll be able to change that entire gnarly mess with simply this:

import 'ember-source/varieties';

Second, chances are you’ll must replace to current variations of ember-qunit, ember-resolver, and @ember/test-helpers, which have themselves been up to date to make use of Ember’s native varieties.

Lastly, you will have to take away the next packages out of your package deal.json file and reinstall your package deal supervisor’s set up command to replace your node_modules:

  • @varieties/ember
  • @varieties/ember__application
  • @varieties/ember__array
  • @varieties/ember__component
  • @varieties/ember__controller
  • @varieties/ember__debug
  • @varieties/ember__destroyable
  • @varieties/ember__engine
  • @varieties/ember__error
  • @varieties/ember__helper
  • @varieties/ember__modifier
  • @varieties/ember__object
  • @varieties/ember__owner
  • @varieties/ember__polyfills
  • @varieties/ember__routing
  • @varieties/ember__runloop
  • @varieties/ember__service
  • @varieties/ember__string
  • @varieties/ember__template
  • @varieties/ember__test
  • @varieties/ember__utils

That is all you might want to do to get pleasure from the brand new TypeScript assist! Nonetheless, there are a pair necessary caveats you need to find out about.


First, and most significantly, these new varieties should not appropriate with the present @varieties definitions for Ember Knowledge. Sadly, Ember Knowledge’s hand-written kind definitions rely in numerous key areas on among the errors within the @varieties packages for Ember—errors which can be mounted through the use of varieties revealed from Ember’s personal supply code. Thus far, the Ember Knowledge group has had too few contributors to make fixing this a high precedence. We made the selection to go forward and publish these secure varieties from Ember anyway for 2 causes:

  • Whereas many Ember customers do depend on Ember Knowledge, not all do, and this makes the absolute best varieties for Ember obtainable to anybody who shouldn’t be blocked on this means.

  • Ember Knowledge itself can now benefit from the Ember varieties! This was a long-standing chicken-or-egg downside: Ember Knowledge might probably not publish its personal secure varieties whereas counting on the hand-written @varieties packages for Ember!

Fortunately, the 2 latest members of the Ember TypeScript group, Peter Wagenet and Krystan HuffMenne, are each actively fascinated with tackling this downside, so there’ll hopefully be good progress on this house in the remainder of 2023. (This can be a excellent spot to chip in and assist, by the way in which!)

Second, Ember’s secure varieties do not need full assist for the Ember Traditional programming mannequin. In case you rely closely on the Ember Traditional programming mannequin, we encourage you to replace your code to the Ember Octane programming mannequin—for many causes! For particulars on absorbing these adjustments specifically, see the Migration Information under.


Due to the interop problem with Ember Knowledge, our TypeScript assist is Launched however not but Advisable. This is without doubt one of the first main options to land in Ember which leans on this distinction in a means that issues to finish customers, so here’s a fast explainer. Since RFC 0617: RFC Phases, options undergo as much as six phases on the way in which to being “accomplished”:

  1. Proposed: A proposal for a change to Ember or its processes that’s provided for group and group analysis.
  2. Exploring: An RFC deemed price pursuing however in want of refinement.
  3. Accepted: A totally specified RFC. Ready for or within the strategy of implementation.
  4. Prepared for Launch: The implementation of the RFC is full, together with studying supplies.
  5. Launched: The work is revealed. Whether it is codebase-related work, it’s in a secure model of the related package deal(s).
  6. Advisable: The function/useful resource is advisable for basic use.

Since TypeScript is Launched, you may depend on all of our regular SemVer ensures. Ember’s varieties are actually a part of our public contract with you as a consumer, they usually must be maintained with the very same care as every other a part of the framework. Moreover, Chris Krycho and the remainder of the Ember TypeScript group developed a spec for Semantic Versioning for TypeScript Sorts, which permits Ember (and every other framework or library) to outline the way it manages supported TypeScript variations and take in breaking adjustments from TypeScript. Which means it’s completely secure so that you can depend on these varieties in case you are not impacted by the caveats described above!

One particular level: as described on our Releases web page, the Ember framework itself makes use of a “rolling window” assist coverage for TypeScript variations. This implies Ember can bump its minimal supported TypeScript model in an Ember minor launch, the identical as it could for Node.js variations—however the supported vary of TypeScript variations throughout two Ember LTS releases should at all times overlap. So if Ember 5.4 LTS helps TypeScript 4.9–5.3, Ember 5.8 LTS might drop assist for TypeScript variations sooner than TypeScript 5.3, however should embrace no less than TypeScript 5.3. That ensures that customers can at all times improve their TypeScript and Ember variations individually. In observe, we count on to take care of a reasonably broad TypeScript model assist window to reduce the affect on the ecosystem—seemingly (although not assured to be) 4 to six current TypeScript variations at any given time.

Ember’s preliminary supported TypeScript model vary is TypeScript 4.9, 5.0, and 5.1.

The one different issues that can change as soon as Ember Knowledge publishes varieties that are appropriate with these and we are able to thus transfer to “Advisable” are:

  • We’ll embrace the related doc feedback or kind imports mechanically when creating new initiatives so everyone seems to be opted into getting these varieties by default, whereas as we speak you have to choose in explicitly.

  • We’ll ultimately take away the @varieties packages completely, to keep away from any potential confusion about what ought to be put in.

Migration Information

For present Ember TypeScript customers, there are a couple of extra adjustments you need to make for adopting the secure varieties.

From the preview varieties

In case you are utilizing the preview varieties we revealed beginning in Ember 4.8, there’s nothing you have to do! Every thing ought to maintain working. Nonetheless, you may be happy to delete the preview kind import out of your varieties/<your-app>/index.d.ts file:

 import 'ember-source/varieties';
-import 'ember-source/varieties/preview';

From DefinitelyTyped

Be aware: this part is similar to the migration information for the preview interval, however has been up to date to account for the adjustments and enhancements we made all through that interval. Thanks to everybody who contributed bug studies and fixes to assist make this remaining product nearly as good because it might be!

In case you are switching to the secure varieties from the @varieties packages from DefinitelyTyped, and you’ve got not already been utilizing the preview varieties, you will have extra work to do to account for the variations between the preview varieties and the definitions on DefinitelyTyped. These variations all fall into one among these broad classes:

  • Fixes to issues within the present definitions.
  • Removing of our (poor!) assist for Ember Traditional class options in favor of native lessons.
  • Adjustments to kind registry dealing with
  • Removing of legacy (non-public) routing APIs

Fixes to issues within the present definitions

Through the preview interval, we recognized and glued numerous kind errors in Ember’s internals, in addition to many locations the @varieties packages have been merely incorrect. Consequently, chances are you’ll discover some variations whenever you swap over. In each case, these symbolize bug fixes, however we acknowledge they could contain some work!

Eradicating assist for Array prototype extensions

This work additionally uncovered numerous errors within the present varieties, particularly round Array prototype extensions. Consequently, these varieties don’t assist Array prototype extensions, and it’s unlikely that future work will be capable to add that assist. (The assist offered by way of the categories on DefinitelyTyped solely labored as a result of the categories have been outlined incorrectly, leading to quite a lot of sorts of unsafety.)

Notably, Array prototype extensions are deprecated and slated for elimination, so transferring off of them is figure you will have to do anyway.

Ember Traditional assist

As laid out in RFC 0800, there are additionally numerous breaking adjustments from the categories in DefinitelyTyped concerning assist for Ember Traditional options:

Per the version assist coverage, we are going to present minimal assist for Ember Traditional options:

  • Ember’s basic class system: we are going to present minimal definitions for the .create(), .prolong(), .reopen(), .reopenClass(), strategies, which make no try to make use of them to truly replace the kinds of the objects they modify.…

  • Ember’s get and set helpers: we is not going to present varieties to make get and set type-safe past property lookups on objects—i.e. no assist for nested path lookups.…

  • Traditional computed property dealing with: we is not going to present “secure” varieties for the basic type of computed properties.

The definitions on DefinitelyTyped tried to make .create() and .prolong() really create up to date varieties, and tried to make .create(), .prolong(), .reopen(), and .reopenClass() have the proper kind for this inside their our bodies. These have been at all times extraordinarily fragile and principally didn’t work. Since Ember 3.6, Ember customers have been ready to make use of native lessons as a substitute of Ember’s basic class system, and this has been the advisable means of writing Ember code for the reason that launch of the Octane version in Ember 3.15.

Within the preview varieties, these strategies are current and are secure to make use of since they’re nonetheless a part of Ember’s public API. Nonetheless, .create() and .prolong() don’t create new varieties. The .create() technique does nonetheless examine that the values you cross match these outlined on the category physique, however the varieties don’t try to make this have the suitable kind inside the our bodies of .create(), .prolong(), .reopen(), or .reopenClass().

Emigrate, you need to:

  • Convert all your individual basic lessons to native lessons.
  • Eradicate your use of mixins.

(Most Ember TypeScript customers have already accomplished this, as a result of these labored so poorly with TypeScript.)

The .create() name can at all times get replaced with a traditional class definition in JavaScript. For every of the others, you can too use declaration merging to symbolize the habits of the tactic in query.


For the case the place you’re solely defining a brand new class, convert to a local class as a substitute. Nonetheless, in case you have code which nonetheless depends on mixins like Evented, you may symbolize it utilizing interface merging like this:

import EmberObject from '@ember/object';
import Evented from '@ember/object/evented';
import kind Proprietor from '@ember/proprietor';

// A local class which nonetheless applies the Evented mixin
class ExtendsDemo extends EmberObject.prolong(Evented) {
  moreStuff = true;

  constructor(proprietor: Proprietor) {
    this.on('customized', this, 'boundMethod');

  willDestroy(): void {'customized', this, 'boundMethod');

  boundMethod = () => {
    alert('do one thing');

// Make that work for the *kind* by merging the kind of the category
// (`interface ExtendsDemo`) with the kind of the mixin (`Evented`)
interface ExtendsDemo extends Evented {}

const occasion = ExtendsDemo.create({
  moreStuff: false,

occasion.set off('customized');

Be aware: you’ll have to disable the @typescript-eslint/no-empty-interface ESLint rule for this.

You are able to do the identical on your personal mixins whereas transitioning by defining an interface which represents the kind of the mixin:

import Mixin from '@ember/object/mixin';

// Creates the runtime mixin code
const Alertable = Mixin.create({
  alert(worth: string) {
    alert(`The worth is ${worth}`);

// Creates the sort for TypeScript to see.
interface Alertable extends Mixin {
  alert(worth: string): void;

// Exports them as a single title in each worth and sort house.
export default Alertable;

Normally, .reopen() is an antipattern, as a result of it makes it very laborious to grasp the place a given a part of a category’ state or habits lives, and you need to transfer away from it! It’s best to desire to delegate to a category as a substitute of dynamically including habits to it, each for maintainability and for efficiency. Nonetheless, for the transition, you may symbolize it utilizing interface merging.

import EmberObject from '@ember/object';

class Foo extends EmberObject {
  someProp = 123;

// That is what makes the change work at runtime...
  additional: 'good day',

// ...whereas that is what makes it seen to the sort system.
interface Foo {
  additional: string;

// Now when calling `Foo.create`, or when working with an occasion of the
// class, each `someProp` and `additional` will probably be checked.
const occasion = Foo.create({
  someProp: 456,
  additional: 'goodbye',

As with .reopen(), using .reopenClass() is an antipattern you need to transfer away from over time, preferring to make use of common features in module scope or regular static strategies on native lessons. Within the meantime, you need to use namespace merging to symbolize the way it works:

import EmberObject from '@ember/object';

class Foo extends EmberObject {
  static someStatic = true;

// This provides the tactic to the Foo class at runtime...
  anotherStatic(): string {
    return 'good day';

// ...and this makes it seen to TypeScript as a static technique.
declare namespace Foo {
  export perform anotherStatic(): string;

if (Foo.someStatic) {

Be aware: you’ll have to disable the @typescript-eslint/no-namespace ESLint rule for this.

Legacy routing kind places

In keeping with [RFC 0821: Public API for Type-Only Imports][0821], this PR additionally removes assist for importing the categories for Transition, RouteInfo, and RouteInfoWithMetadata from the non-public places that DefinitelyTyped presently helps for backwards compatibility. Customers might want to migrate to utilizing the proper import paths when switching to make use of these imports.

  • import Transition from '@ember/routing/-private/transition' → import Transition from '@ember/routing/transition'
  • import RouteInfo from '@ember/routing/-private/route-info' → import RouteInfo from '@ember/routing/route-info'
  • import { RouteInfoWithMetadata } from '@ember/routing/-private/route-info-with-metadata' → import { RouteInfoWithMetadata } from '@ember/routing/route-info'


Since 2017, Ember has had TypeScript assist by way of the @varieties packages revealed from DefinitelyTyped. In Ember 4.8, we started publishing a preview of varieties revealed with Ember itself. These kind definitions have been written by hand, so that they have been generally incorrect. We at all times did our greatest to match them as much as the truth of Ember’s supply code, nevertheless it was by no means good. With this launch, we not publish any hand-authored varieties for Ember itself. As an alternative, the sort come straight from Ember’s personal TypeScript supply. This implies they’re at all times in sync with Ember itself—they can’t be unintentionally incorrect.

Provided that Ember’s supply has been written in TypeScript for years, why did it take us so lengthy to get right here? For one factor, we wanted to determine to make TypeScript a first-class language and provide you with a plan for transport it. For an additional, Ember’s internals wanted a lot of polish to be able to publish. Like many TypeScript code bases, Ember began off as a JavaScript-only code base, and its conversion happend in suits and begins over a few years. Some elements of it have been nonetheless completely in JavaScript even solely a 12 months in the past. Lastly, we wanted to construct some customized construct infrastructure to make the categories usable, because you depend upon ember-source in your package deal.json file, however import from packages like @ember/proprietor.

In case you’re curious in regards to the nitty-gritty particulars, you may try the construct script used to generate varieties from Ember’s supply. Moreover, this YouTube video features a detailed walkthrough of the mechanics of publishing our varieties:


This can be a big step for Ember’s TypeScript assist. Together with Glint 1.0, Ember CLI 4.12’s --typescript assist, enhancements to our testing story, and making <template> viable, we now have accomplished all the important thing work required for Ember itself to have top-notch TypeScript assist. Up subsequent: getting Ember Knowledge throughout the road!

Thanks to everybody who has contributed to this huge milestone, and to AuditBoard, LinkedIn, Salsify, and Tilde for sponsoring engineering time to get this mammoth process accomplished.



Please enter your comment!
Please enter your name here

Most Popular

Recent Comments