Ember 4 Octane Only

Ember 4.x — The Octane-Only Era

4.x is where the classic API stopped being a fallback. Code that still ran on 3.28 with deprecation warnings now fails to compile on 4.x. This skill enumerates what's gone, what survives, and what's new (specific to the 4.x window) that 5.x then reshaped.

The mental model

Identical to the ember-octane-fundamentals skill. If you can write modern Octane (native classes, @tracked, @action, @service, modifiers), you can write 4.x.

4.x-specific reminder: the <template> tag (.gjs/.gts) is not in 4.x. Stay on classic colocated .ts + .hbs files (or .js + .hbs).

What's gone in 4.x (vs. late 3.x)

What is new in 4.x

What survives unchanged

These are exactly the same in 4.x as in 3.x-Octane and 5.x:

• Routing API (Router.map, route hooks, RouterService).
• @service injection and the container.
• @tracked semantics.
• @action semantics.
• @cached for memoized getters.
• Component signatures (Args / Element / Blocks).
• Mirage, page-object, test-selectors, intl, simple-auth, concurrency, modifier — all major addons work the same way.

What's not yet in 4.x

These are 5.x+ features. If you see them, the reader is in 5.x territory or aspirational:

• <template> tag in .gjs/.gts files. Not available; you author .ts + .hbs.
• Strict-mode templates (template imports). Not available.
• Glint's ember-template-imports environment. The ember-loose environment partially works but with rough edges; many teams disable Glint on 4.x.
• The new ember-data request manager (@ember-data/request) as the default. Available for opt-in late in 4.x; default in 5.x.
• WarpDrive branding for the next-gen ember-data. (5.x+.)
• Native browser-supported decorators. 4.x still uses TS legacy/experimental decorators.

Anatomy of a 4.x component

// app/components/post-card.ts
import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';
import { action } from '@ember/object';
import { service } from '@ember/service';
import type RouterService from '@ember/routing/router-service';
import type PostModel from 'my-app/models/post';

export interface PostCardSignature {
  Args: {
    post: PostModel;
  };
  Element: HTMLElement;
}

export default class PostCard extends Component<PostCardSignature> {
  @service declare router: RouterService;
  @tracked isExpanded = false;

  @action toggle() {
    this.isExpanded = !this.isExpanded;
  }
}

{{! app/components/post-card.hbs }}
<article ...attributes>
  <h2>{{@post.title}}</h2>
  {{#if this.isExpanded}}
    <p>{{@post.body}}</p>
  {{/if}}
  <button type="button" {{on "click" this.toggle}}>
    {{if this.isExpanded "Collapse" "Expand"}}
  </button>
</article>

This is identical to a modern Ember component minus the <template> tag.

Anatomy of a 4.x service

// app/services/cart.ts
import Service from '@ember/service';
import { tracked } from '@glimmer/tracking';
import { cached } from '@glimmer/tracking';

export default class CartService extends Service {
  @tracked items: CartItem[] = [];

  @cached
  get subtotal(): number {
    return this.items.reduce((s, i) => s + i.price * i.quantity, 0);
  }

  add(item: CartItem) { this.items = [...this.items, item]; }
  remove(id: string) { this.items = this.items.filter(i => i.id !== id); }
}

declare module '@ember/service' {
  interface Registry {
    cart: CartService;
  }
}

Anatomy of a 4.x ember-data model

// app/models/post.ts
import Model, { attr, belongsTo, hasMany } from '@ember-data/model';
import type { AsyncBelongsTo, AsyncHasMany } from '@ember-data/model';
import type UserModel from './user';
import type CommentModel from './comment';

export default class PostModel extends Model {
  @attr('string') declare title: string;
  @attr('string') declare body: string;
  @attr('boolean', { defaultValue: false }) declare isDraft: boolean;

  @belongsTo('user', { async: true, inverse: 'posts' })
    declare author: AsyncBelongsTo<UserModel>;

  @hasMany('comment', { async: true, inverse: 'post' })
    declare comments: AsyncHasMany<CommentModel>;
}

declare module 'ember-data/types/registries/model' {
  export default interface ModelRegistry {
    post: PostModel;
  }
}

4.x-specific: the inverse and async options on relationships are now errors if missing (in late 4.x), not just deprecation warnings. If your 3.x → 4.x migration left them implicit, fix them all.

Build pipelines available in 4.x

You'll see these in the wild, in roughly this order:

1. Classic ember-cli (default in early 4.x, still works through 4.12). Broccoli/Babel-based; no tree-shaking.
2. Embroider compat (@embroider/core + @embroider/compat + @embroider/webpack). Drop-in, tree-shakes static usage, prepares for optimized mode.
3. Embroider optimized (staticHelpers: true, staticModifiers: true, staticComponents: true, staticAddonTrees: true). Real ES module pipeline. Required for <template> tag in 5.x.

For a 4.x codebase you maintain through 2026, adopt Embroider at minimum in compat mode. It's a separate week of work, but it pays back in build performance and prepares the 5.x jump.

Common 4.x mistakes

Verification

• No @ember/component imports.
• No Ember.X global imports.
• No (mut ...) in templates.
• No actions: {} in classes.
• All ember-data relationships specify async and inverse explicitly.
• Tests on module + setupXxxTest.
• (Recommended) Embroider in compat mode at minimum.

See also

• ember-4-typescript-early — adopting TS on 4.x.
• ember-4-recommendations — Embroider, addons, and the 5.x roadmap.
• ember-4-to-5-migration — the next jump.
• Modern reference: ember-octane-fundamentals.