EmberObject, there are a number of caveats and limitations you need to be aware of. For today, these caveats and limitations apply to any classes which extend directly from EmberObject, or which extend classes which themselves extend EmberObject:Component – meaning classic Ember components, which imported from @ember/component, not Glimmer components which are imported from @glimmer/component and do not extend the EmberObject base class.ControllerHelper – note that this applies only to the class form. Function-based helpers do not involve the EmberObject base class.RouteRouterServiceModel classEmberObject, and it has the most caveats and limitations.EmberObject base class dependency, but that will not happen till at least the next major version of Ember, and these guides will be updated when that happens..extend({ ... }) syntax, regardless of whether there is a named mixin involved, you are dealing with Ember's legacy mixin system. This in turn means that you are dealing with the parts of Ember which TypeScript is least able to handle well.this in actions hashes, computed properties, etc. That in turn often leads to problems with self-referential this: TypeScript simply cannot figure out how to stop recursing through the definitions of the type.EmberObjectEmberObject base class eliminate any use of EmberObject-specific API and convert to standalone class, with no base class at all. You can follow the ember-classic-decorator workflow to eliminate the base class—switching from init to constructor, getting rid of uses of methods like this.set and this.get in favor of using standalone set and get, and so on.EmberObject-descended classesEmberObject cannot follow the exact same path. However, as long as you are using native class syntax, all of these (Component, Controller, Helper, etc.) work nicely and safely with TypeScript. In each of these cases, the same caveats apply as with EmberObject itself, and you should follow the ember-classic-decorator workflow with them as well if you are converting an existing app or addon. However, because these base classes themselves descend from EmberObject, you will not be able to remove the base classes as you can with your own classes which descend directly from EmberObject. Instead, you will continue to extend from the Ember base classes: