From 25d18524964dce480f0b5a05b3b72b9b8215cb9e Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Tue, 8 Sep 2026 12:49:36 -0400 Subject: [PATCH 01/11] Deprecate EmberObject --- text/1234-deprecate-ember-object.md | 91 +++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 text/1234-deprecate-ember-object.md diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md new file mode 100644 index 0000000000..fcf280ae85 --- /dev/null +++ b/text/1234-deprecate-ember-object.md @@ -0,0 +1,91 @@ +--- +stage: accepted +start-date: +release-date: +release-versions: +teams: # delete teams that aren't relevant + - cli + - data + - framework + - learning + - steering + - typescript +prs: + accepted: # update this to the PR that you propose your RFC in +project-link: +--- + + + +<-- Replace "RFC title" with the title of your RFC --> +# RFC Title + +## Summary + +> One paragraph explanation of the deprecation. + +## Motivation + +> Why are we doing this? What are the problems with the deprecated feature? +What is the replacement functionality? + +## Transition Path + +> This is the bulk of the RFC. Explain the use-cases that deprecated functionality +covers, and for each use-case, describe the transition path. +Describe it in enough detail for someone who uses the deprecated functionality +to understand, for someone to write the deprecation guide, and for someone +familiar with the implementation to implement. + +> It can be helpful to write the deprecation guide as part of this section. Published deprecation +> guides can be found at https://deprecations.emberjs.com/. + +> Please keep in mind any implications within the Ember ecosystem, such as: +> - Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed +> - Features that are replaced or made obsolete by this feature and should eventually be deprecated +> - Ember Inspector and debuggability +> - Server-side Rendering +> - Ember Engines +> - The Addon Ecosystem +> - IDE Support +> - Blueprints that should be added or modified + +## How We Teach This + +> Would the acceptance of this proposal mean the Ember guides must be +re-organized or altered? Does it change how Ember is taught to new users +at any level? +Does it mean we need to put effort into highlighting the replacement +functionality more? What should we do about documentation, in the guides +related to this feature? +How should this deprecation be introduced and explained to existing Ember +users? + +> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc. + +## Drawbacks + +> Why should we *not* do this? Please consider the impact on teaching Ember, +on the integration of this feature with other existing and planned features, +on the impact of the API churn on existing apps, etc. +There are tradeoffs to choosing any path, please attempt to identify them here. + +## Alternatives + +> What other designs have been considered? What is the impact of not doing this? + +## Unresolved questions + +> Optional, but suggested for first drafts. What parts of the design are still +TBD? From d0a47d4bb4666b1ec8d20b8a36c68e58fb0d3f4a Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Tue, 8 Sep 2026 13:05:41 -0400 Subject: [PATCH 02/11] Summary/Motivation/etc --- text/1234-deprecate-ember-object.md | 61 ++++++++++++++--------------- 1 file changed, 30 insertions(+), 31 deletions(-) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index fcf280ae85..0705e16988 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -11,7 +11,7 @@ teams: # delete teams that aren't relevant - steering - typescript prs: - accepted: # update this to the PR that you propose your RFC in + accepted: https://github.com/emberjs/rfcs/pull/1234 project-link: --- @@ -28,38 +28,39 @@ prs: project-link: Leave as is --> -<-- Replace "RFC title" with the title of your RFC --> -# RFC Title +# Deprecate EmberObject ## Summary -> One paragraph explanation of the deprecation. +Deprecates `EmberObject` in a way that is initually opt-in, so people can more gradually prepare their codebase for the removal of `EmberObject`. + ## Motivation -> Why are we doing this? What are the problems with the deprecated feature? -What is the replacement functionality? +`EmberObject` has had heavy use in the early days of Ember (pre-JavaScript having classes), and since classes shipped in 2015, the need for `EmberObject` has greatly diminished. + +Removing `EmberObject` is one of the last steps in coercing codebases to be plain modern JavaScript. ## Transition Path -> This is the bulk of the RFC. Explain the use-cases that deprecated functionality -covers, and for each use-case, describe the transition path. -Describe it in enough detail for someone who uses the deprecated functionality -to understand, for someone to write the deprecation guide, and for someone -familiar with the implementation to implement. - -> It can be helpful to write the deprecation guide as part of this section. Published deprecation -> guides can be found at https://deprecations.emberjs.com/. - -> Please keep in mind any implications within the Ember ecosystem, such as: -> - Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed -> - Features that are replaced or made obsolete by this feature and should eventually be deprecated -> - Ember Inspector and debuggability -> - Server-side Rendering -> - Ember Engines -> - The Addon Ecosystem -> - IDE Support -> - Blueprints that should be added or modified +Unlike previous deprecations, this is targeting Ember 9, and will have a feature flag that removes all behavior related to `EmberObject`. This does require a lot of internal implementation in `ember-source`, but is needed anyway for the removal of `EmberObject`, ultimately. + +This will be the first deprecation that users will be able to preview the removal off. + +Leading up to v8, the feature flag will be "off": +- deprecation logged for all EmberObject APIs (even thoose acessible through framework objects (get/set/etc)) +- EmberObject is still usable + +With the release of v8, and leading up to v9, the feature flag will be "on" by default: +- EmberObject (and related APIs) is/are not usable, due to the feature flag removing all of the implementation +- if users wish, the feature flag can be flipped back off, which brings back the EmberObject behavior along with the deprecations + +At `ember-source` v9, `EmberObject` is removed fully along with the feature flag. + + +> [!NOTE] +> This includes `@computed`, as `@computed` is part of the "Ember Object Model" of reactivity. + ## How We Teach This @@ -76,16 +77,14 @@ users? ## Drawbacks -> Why should we *not* do this? Please consider the impact on teaching Ember, -on the integration of this feature with other existing and planned features, -on the impact of the API churn on existing apps, etc. -There are tradeoffs to choosing any path, please attempt to identify them here. +keeping EmberObject is a drawback, because of the dozens of KB that come along with it. + +all codebases with old code probably have some usage of EmberObject remaining, so they need to migrate. ## Alternatives -> What other designs have been considered? What is the impact of not doing this? +- do nothing ## Unresolved questions -> Optional, but suggested for first drafts. What parts of the design are still -TBD? +n/a From 109ac98eb65a1f521de5cbb7e773fc1a1236f6e3 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Tue, 8 Sep 2026 13:08:01 -0400 Subject: [PATCH 03/11] impl note --- text/1234-deprecate-ember-object.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index 0705e16988..a8b422b7be 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -62,6 +62,10 @@ At `ember-source` v9, `EmberObject` is removed fully along with the feature flag > This includes `@computed`, as `@computed` is part of the "Ember Object Model" of reactivity. +Internally, implementation would likely be similar to how Mixins were initially deprecated -- copied to an "internal" file, and then the "public" version of `EmberObject` would override `init`, and provide the deprecations. + +On the internal copy of `EmberObject`, we deprecate all the methods (`get`, / `set` / etc), so that the deprecations flow through to other framework classes such as `Route`, `Controller`, `Service`, etc. + ## How We Teach This > Would the acceptance of this proposal mean the Ember guides must be From 192158451d75d798da0aa4503021646294b92bd9 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Tue, 8 Sep 2026 15:06:24 -0400 Subject: [PATCH 04/11] Clarify that the deprecation is about the feature flag: this helps not overwhelm users --- text/1234-deprecate-ember-object.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index a8b422b7be..16ca00e780 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -48,12 +48,12 @@ Unlike previous deprecations, this is targeting Ember 9, and will have a feature This will be the first deprecation that users will be able to preview the removal off. Leading up to v8, the feature flag will be "off": -- deprecation logged for all EmberObject APIs (even thoose acessible through framework objects (get/set/etc)) -- EmberObject is still usable +- deprecation logged for not having this feature flag "on" +- EmberObject and all related APIs are still usable With the release of v8, and leading up to v9, the feature flag will be "on" by default: -- EmberObject (and related APIs) is/are not usable, due to the feature flag removing all of the implementation -- if users wish, the feature flag can be flipped back off, which brings back the EmberObject behavior along with the deprecations +- EmberObject and related APIs are not usable, due to the feature flag removing all of the implementation +- if users wish, the feature flag can be flipped back off, which brings back the EmberObject behavior along with the deprecation At `ember-source` v9, `EmberObject` is removed fully along with the feature flag. From 51c7bc6aee38c76bf9a04829fe10e9ab32125718 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Sat, 12 Sep 2026 11:31:29 -0400 Subject: [PATCH 05/11] Add deprecation guides --- text/1234-deprecate-ember-object.md | 250 ++++++++++++++++++++++++++-- 1 file changed, 240 insertions(+), 10 deletions(-) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index 16ca00e780..6f6c1f0247 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -49,7 +49,7 @@ This will be the first deprecation that users will be able to preview the remova Leading up to v8, the feature flag will be "off": - deprecation logged for not having this feature flag "on" -- EmberObject and all related APIs are still usable +- EmberObject and all related APIs are still usable (unless the feature flag is "on") With the release of v8, and leading up to v9, the feature flag will be "on" by default: - EmberObject and related APIs are not usable, due to the feature flag removing all of the implementation @@ -68,16 +68,246 @@ On the internal copy of `EmberObject`, we deprecate all the methods (`get`, / `s ## How We Teach This -> Would the acceptance of this proposal mean the Ember guides must be -re-organized or altered? Does it change how Ember is taught to new users -at any level? -Does it mean we need to put effort into highlighting the replacement -functionality more? What should we do about documentation, in the guides -related to this feature? -How should this deprecation be introduced and explained to existing Ember -users? +The guides have not taught `EmberObject` since Octane. The work is: -> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc. +- publish the deprecation guide below at [deprecations.emberjs.com](https://deprecations.emberjs.com) +- mark `EmberObject`, `@computed`, and the `@ember/object/computed` macros deprecated in the API docs, linking to the guide +- link the [Octane vs Classic cheat sheet](https://guides.emberjs.com/release/upgrading/current-edition/) from the deprecation message; it already has the before/afters + +### Deprecation Guide + +The deprecation fires once per app boot while the feature flag is off. Turning the flag on removes `EmberObject` from the build, which is how you confirm the migration is complete. + +```js +deprecate(message, false, { + id: 'deprecate-ember-object', + until: '9.0.0', + for: 'ember-source', + url: 'https://deprecations.emberjs.com/id/deprecate-ember-object', + since: { available: '7.x', enabled: '7.x' }, +}); +``` + +#### What is deprecated + +| | API | status | +| - | --- | ------ | +| 🌐 | `EmberObject` (default export of `@ember/object`) | **deprecated** | +| 🌐 | `this.get` / `this.set` / `setProperties` / `getProperties` / `incrementProperty` / `toggleProperty` / `notifyPropertyChange` on any class that extends `EmberObject`, including `Route`, `Controller`, `Service` | **deprecated** | +| 🌐 | `init`, `willDestroy`, `destroy`, `isDestroying`, `isDestroyed` as `EmberObject` methods | **deprecated** | +| 🌐 | `reopen` / `reopenClass` | **deprecated** | +| 🌐 | `@computed` and the `@ember/object/computed` macros | **deprecated** | + +Related deprecations with their own guides: + +- [`.extend()` / `.create()`](https://rfcs.emberjs.com/id/1117-deprecate-classic-classes) +- [Mixins](https://rfcs.emberjs.com/id/1116-deprecate-mixins) +- [observers](https://github.com/emberjs/rfcs/pull/1115) +- [`EmberArray` / `A()`](https://rfcs.emberjs.com/id/1114-deprecate-ember-array) +- [`ObjectProxy` / `ArrayProxy`](https://rfcs.emberjs.com/id/1112-deprecate-proxy) +- [`Evented`](https://rfcs.emberjs.com/id/1111-deprecate-evented-mixin) +- [`@ember/component`](https://rfcs.emberjs.com/id/1216-deprecate-ember-component) + +#### Migration + +
Your own class extends EmberObject + +```js +// before +import EmberObject from '@ember/object'; + +export default class Cart extends EmberObject { + items = []; + + init() { + super.init(...arguments); + this.total = 0; + } +} + +let cart = Cart.create({ currency: 'USD' }); +``` + +```js +// after +export default class Cart { + items = []; + total = 0; + + constructor({ currency }) { + this.currency = currency; + } +} + +let cart = new Cart({ currency: 'USD' }); +``` + +`create()` assigned every key of its argument onto the instance. A constructor receives the same object and assigns what it needs. + +
+ +
this.get / this.set + +```js +// before +this.set('count', this.get('count') + 1); +this.setProperties({ name, email }); +let { name, email } = this.getProperties('name', 'email'); +this.incrementProperty('count'); +this.toggleProperty('isOpen'); +this.get('user.address.city'); +``` + +```js +// after +this.count = this.count + 1; +Object.assign(this, { name, email }); +let { name, email } = this; +this.count++; +this.isOpen = !this.isOpen; +this.user?.address?.city; +``` + +Assignment only results in a rerender when the property is `@tracked`. [ember-tracked-properties-codemod](https://github.com/ember-codemods/ember-tracked-properties-codemod) adds `@tracked` to properties that `set` wrote to. The `ember/no-get` lint rule autofixes the reads. + +`notifyPropertyChange` has no replacement. With `@tracked`, the write is the notification. + +
+ +
@computed + +```js +// before +import { computed } from '@ember/object'; +import { alias, filterBy, sort } from '@ember/object/computed'; + +export default class Cart extends EmberObject { + @computed('items.@each.price') + get total() { + return this.items.reduce((sum, item) => sum + item.price, 0); + } + + @alias('user.name') owner; + @filterBy('items', 'isGift', true) gifts; + @sort('items', 'sortKeys') sorted; +} +``` + +```js +// after +import { cached } from '@glimmer/tracking'; + +export default class Cart { + @cached + get total() { + return this.items.reduce((sum, item) => sum + item.price, 0); + } + + get owner() { return this.user.name; } + get gifts() { return this.items.filter((item) => item.isGift); } + get sorted() { return this.items.toSorted(byKeys(this.sortKeys)); } +} +``` + +Dependent keys go away. A getter re-runs when any `@tracked` value it read changes. Use `@cached` only when the getter is expensive. + +
+ +
willDestroy / destroy() + +```js +// before +export default class Poller extends EmberObject { + init() { + super.init(...arguments); + this.timer = setInterval(this.tick, 1000); + } + + willDestroy() { + clearInterval(this.timer); + super.willDestroy(...arguments); + } +} + +poller.destroy(); +``` + +```js +// after +import { registerDestructor, destroy } from '@ember/destroyable'; + +export default class Poller { + constructor() { + this.timer = setInterval(this.tick, 1000); + registerDestructor(this, () => clearInterval(this.timer)); + } +} + +destroy(poller); +``` + +`isDestroying` and `isDestroyed` are also exported from `@ember/destroyable`. `Route`, `Controller`, and `Service` keep `willDestroy`. + +
+ +
Route, Controller, Service + +Only the `EmberObject` methods on these classes are deprecated: + +```js +// before +import Service from '@ember/service'; +import { computed } from '@ember/object'; + +export default class Session extends Service { + init() { + super.init(...arguments); + this.set('user', null); + } + + @computed('user') + get isLoggedIn() { + return Boolean(this.get('user')); + } +} +``` + +```js +// after +import Service from '@ember/service'; +import { tracked } from '@glimmer/tracking'; + +export default class Session extends Service { + @tracked user = null; + + get isLoggedIn() { + return Boolean(this.user); + } +} +``` + +
+ +
reopen / reopenClass + +```js +// before +Cart.reopen({ currency: 'USD' }); +Cart.reopenClass({ fromJSON(json) { /* ... */ } }); +``` + +```js +// after +export default class Cart { + currency = 'USD'; + + static fromJSON(json) { /* ... */ } +} +``` + +If the class is not yours, you may use the Presenter pattern for wrapping/enriching the source data. Addons that expected consumers to `reopen` their classes need to expose a configuration API instead. + +
## Drawbacks From c9ec5226fbc40d3abbbc52bf656bb8003c4f3fda Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Sat, 12 Sep 2026 11:33:00 -0400 Subject: [PATCH 06/11] Fix frontmatter --- text/1234-deprecate-ember-object.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index 6f6c1f0247..68ea461ddc 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -1,6 +1,6 @@ --- stage: accepted -start-date: +start-date: 2026-10-08T00:00:00.000Z release-date: release-versions: teams: # delete teams that aren't relevant From 9af3d47f9d5a598bd75dc27a132d968061617245 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Mon, 21 Sep 2026 11:39:54 -0400 Subject: [PATCH 07/11] Fix typos and clarify EmberObject deprecation details Corrected typos and clarified the feature flag behavior for the deprecation of EmberObject. --- text/1234-deprecate-ember-object.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index 68ea461ddc..7f56f02206 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -45,15 +45,23 @@ Removing `EmberObject` is one of the last steps in coercing codebases to be plai Unlike previous deprecations, this is targeting Ember 9, and will have a feature flag that removes all behavior related to `EmberObject`. This does require a lot of internal implementation in `ember-source`, but is needed anyway for the removal of `EmberObject`, ultimately. -This will be the first deprecation that users will be able to preview the removal off. - -Leading up to v8, the feature flag will be "off": -- deprecation logged for not having this feature flag "on" -- EmberObject and all related APIs are still usable (unless the feature flag is "on") +This will be the first deprecation that users will be able to preview the removal of. + +Leading up to v8, the feature flag will be: + - for existing apps: "off" (someone who hasn't updated their `optional-features.json`): + - deprecation logged for not having this feature flag "on" + - EmberObject and all related APIs are still usable (unless the feature flag is "on") + - for the blueprint: "on" (the setting in `optional-features.json` is set to `true`: + - new apps cannot throw deprecations, so new apps get the benefits of this feature flag being "on" right away + +When the feature flag is "on": + - each API-to-be-removed will throw an error (until we ship the build-time feature-stripping for all the EmberObject and related code) + - ideally, setting the feature flag to "on" _removes_ all of the implementation for EmberObject, though this is not a blocker for the deprecation's behavior + - if we aren't able to implement removal in the initial release, we will implement the removal in a future minor release With the release of v8, and leading up to v9, the feature flag will be "on" by default: -- EmberObject and related APIs are not usable, due to the feature flag removing all of the implementation - if users wish, the feature flag can be flipped back off, which brings back the EmberObject behavior along with the deprecation +- when no `optional-features.json` is present, or the `optional-features.json` does not contain the feature flag for this deprecation, the default value is assumed to be "on" At `ember-source` v9, `EmberObject` is removed fully along with the feature flag. From 93b6a15d331eff212b153f9635779adddc32bdfd Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Mon, 21 Sep 2026 11:42:57 -0400 Subject: [PATCH 08/11] Update deprecation message for EmberObject Clarify deprecation behavior of EmberObject in the guide. --- text/1234-deprecate-ember-object.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index 7f56f02206..96b2e14d31 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -84,7 +84,7 @@ The guides have not taught `EmberObject` since Octane. The work is: ### Deprecation Guide -The deprecation fires once per app boot while the feature flag is off. Turning the flag on removes `EmberObject` from the build, which is how you confirm the migration is complete. +The deprecation fires once per app boot while the feature flag is off. ```js deprecate(message, false, { From 12b82e470826e3b7c3ef7793958a284ee5dda3e7 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Mon, 21 Sep 2026 11:53:04 -0400 Subject: [PATCH 09/11] Update deprecation guide for EmberObject Added a note about migration and linked to Octane guides. --- text/1234-deprecate-ember-object.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index 96b2e14d31..1bd21bb365 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -118,6 +118,8 @@ Related deprecations with their own guides: #### Migration +These are only small examples. For a full guide, see the [Octane migration guides](https://guides.emberjs.com/v5.12.0/upgrading/current-edition/). +
Your own class extends EmberObject ```js From bf552af73dfb7b7fd68a8f458ae8b91d950e0d8e Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Mon, 21 Sep 2026 11:55:26 -0400 Subject: [PATCH 10/11] Fix typo in deprecation summary for EmberObject --- text/1234-deprecate-ember-object.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index 1bd21bb365..c6bbe34c63 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -32,7 +32,7 @@ project-link: Leave as is ## Summary -Deprecates `EmberObject` in a way that is initually opt-in, so people can more gradually prepare their codebase for the removal of `EmberObject`. +Deprecates `EmberObject` in a way that is initially opt-in, so people can more gradually prepare their codebase for the removal of `EmberObject`. ## Motivation From b6c5c15093c5dc14980754586d4dd13ac7284599 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Mon, 21 Sep 2026 12:05:33 -0400 Subject: [PATCH 11/11] Update deprecation guide for Ember Object Clarify deprecation message behavior and link to cheat sheet. --- text/1234-deprecate-ember-object.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/1234-deprecate-ember-object.md b/text/1234-deprecate-ember-object.md index c6bbe34c63..465e958e6e 100644 --- a/text/1234-deprecate-ember-object.md +++ b/text/1234-deprecate-ember-object.md @@ -84,7 +84,8 @@ The guides have not taught `EmberObject` since Octane. The work is: ### Deprecation Guide -The deprecation fires once per app boot while the feature flag is off. +> [!NOTE] +> We are aware that this could be a very noisy deprecation, and are investigating ways to reduce that noise in a digestible way -- this _could_ mean only logging the deprecation once, for example - but would then mean people can only resolve one violation at a time after turning on the feature flag. ```js deprecate(message, false, {