菜单
Practical advice for teams settling on Ember 3.28 LTS as a checkpoint — when to keep going to 4.x, when to pause, what to do during the pause. Use when triaging a 3.28 codebase, deciding whether to invest in Octane within 3.x first, or planning a quarterly upgrade roadmap.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | ember-3-recommendations |
| description | Practical advice for teams settling on Ember 3.28 LTS as a checkpoint — when to keep going to 4.x, when to pause, what to do during the pause. Use when triaging a 3.28 codebase, deciding whether to invest in Octane within 3.x first, or planning a quarterly upgrade roadmap. |
| type | feedback |
3.28 is the longest-lived 3.x LTS and a defensible checkpoint in a long upgrade journey. It is not a defensible long-term home. Security patches for 3.x stopped in 2023; running 3.28 in 2026 is in the same risk class as running 2.x in 2020.
| Situation | Recommendation |
|---|---|
| 3.28, classic syntax everywhere, thin tests | Pause. Adopt Octane within 3.x first (see ember-3-octane-adoption). Then proceed to 4.x. |
| 3.28, fully Octane, strong tests, jQuery removed | Press on. 3 → 4 is one of the easier jumps. Don't linger here. |
| 3.16-3.27, mid-Octane | Keep moving to 3.28 first; the deprecation messages in 3.20+ are clearer signal than 3.16's. |
| 3.4 LTS or earlier 3.x | Catch up to 3.28 before doing anything else. |
The shape of the code matters more than the version number. Octane shape on 3.28 is a much better starting point for the 4.x jump than classic shape on 3.28.
If you're going to sit on 3.28 for a quarter or two while finishing Octane adoption:
ember-source@~3.28.x, ember-cli@~3.28.x, ember-data@~3.28.x. Lockfile committed.data-test-* selectors everywhere.@embroider/core + @embroider/compat + @embroider/webpack. This is a separate project; it's the hardest single change in the migration arc. Many teams skip Embroider on 3.x and adopt it during 4.x.A common mistake: "Let's just bump to 4.x, then adopt Octane." Don't. 4.x requires Octane. If you bump first, you discover every classic pattern at once, while also fighting major-version removals and an ember-data 4.x typing rewrite. Conversely, doing Octane on 3.28:
Most teams that struggle with the 4.x jump are teams that didn't finish Octane in 3.x.
Things to actively check:
ember-i18n is dead; use ember-intl. Old date pickers may have current alternatives.A practical script: list addons in package.json, look each up on emberobserver.com, decide keep/replace/fork. Bake the decision into a MIGRATION.md in the repo.
ember-test-selectors — keeps tests independent of design.ember-cli-page-object — fine through every version.ember-power-select — keep current major.ember-cli-deprecation-workflow — your friend during every upgrade.moduleForComponent). All new tests on the modern API.ember-cli-typescript-era setup, but expect to redo it later.)template-lint --config octane blocks classic-only patterns.eslint-plugin-ember's octane ruleset blocks Ember.Component.extend, actions: {}, etc.deprecation-workflow.js (the file should shrink or stay the same, never grow).ember-template-lint deny-list rules for (mut ...) in templates (or upgrade-block rule).Before you start the 4.x bump:
release/3.28 branch from your latest green main.v-pre-4-upgrade.release/3.28 for the duration of the migration.If something explodes during the 4.x window, you can ship a 3.28 fix without unwinding the migration.
app/components/.(mut ...) in templates.Ember.X global imports.this.$() in product code.package.json (i.e., no addon will block a 4.x bump).module + setupApplicationTest/setupRenderingTest.release/3.28 branch exists for emergency fixes.When that's all checked, switch to ember-3-to-4-migration and start the bump.
ember-3-octane-adoption — the prerequisite for a clean 4.x jump.ember-3-to-4-migration — the next step.ember-2-recommendations — analogous skill for the previous version.Curated picks from emberobserver.com — auth, async, testing, forms/UI, i18n, observability, build & lint. Use when picking an addon, debugging "what does this addon do," or scaffolding a new feature that should reuse community standards.
Testing Ember apps — QUnit + @ember/test-helpers, the unit/integration/application split, ember-test-selectors, ember-cli-page-object, ember-cli-mirage, accessibility checks, and async settledness. Use when writing or fixing tests, designing a test strategy, or debugging flaky/non-settled tests.
The Ember 2.x test API — moduleFor, moduleForComponent, moduleForModel, moduleForAcceptance, the global async helpers (visit, click, fillIn), wait(), and the bridge to the modern setupTest/setupRenderingTest API introduced in 3.x. Use when reading or fixing 2.x tests, or when planning the conversion to the modern qunit-based API.
The canonical Ember 2.x mental model — Ember.Object.extend, Ember.computed, classic components, the actions hash, mixins, observers, run loop, two-way binding. Use when reading or maintaining 2.x code, decoding deprecation messages, or explaining how a 2.x pattern maps to modern Ember.
Adopting Octane within an Ember 3.16+ app — optional features, ember-octane-codemods, per-file conversion order. Use when converting a 3.x app from classic to Octane, scoping the effort, or reviewing an Octane-conversion PR.
Practical advice for teams that must stay on Ember 2.x for now — pinning, security hygiene, what to backport, what to leave alone, when to declare upgrade-impossible-without-rewrite. Use when triaging a frozen 2.x codebase, when justifying upgrade budget, or when scoping the smallest viable maintenance footprint.