Skip to content

Deprecate @ember/runloop - #1219

Open
NullVoxPopuli wants to merge 2 commits into
mainfrom
nvp/deprecate-the-runloop
Open

Deprecate @ember/runloop#1219
NullVoxPopuli wants to merge 2 commits into
mainfrom
nvp/deprecate-the-runloop

Conversation

@NullVoxPopuli

Copy link
Copy Markdown
Contributor

Propose Deprecating @ember/runloop

Rendered

Summary

This pull request is proposing a new RFC.

To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.

A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.

An FCP is required before merging this PR to advance to Accepted.

Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.

Exploring Stage Description

This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.

An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an Exploring label applied.

An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.

Accepted Stage Description

To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.

If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.

When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.

Checklist to move to Exploring

  • The team believes the concepts described in the RFC should be pursued.
  • The label S-Proposed is removed from the PR and the label S-Exploring is added.
  • The Ember team is willing to work on the proposal to get it to Accepted

Checklist to move to Accepted

  • This PR has had the Final Comment Period label has been added to start the FCP
  • The RFC is announced in #news-and-announcements in the Ember Discord.
  • The RFC has complete prose, is well-specified and ready for implementation.
    • All sections of the RFC are filled out.
    • Any unanswered questions are outlined and expected to be answered before Ready for Release.
    • "How we teach this?" is sufficiently filled out.
  • The RFC has a champion within one of the relevant teams.
  • The RFC has consensus after the FCP period.

@github-actions github-actions Bot added the S-Proposed In the Proposed Stage label Aug 4, 2026
@NullVoxPopuli
NullVoxPopuli marked this pull request as ready for review August 4, 2026 16:58
The replacement is explicit, and better -- [`@ember/test-waiters`](https://github.com/emberjs/ember-test-waiters):

```js
import { buildWaiter } from '@ember/test-waiters';

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't like that production code has to be test-aware. is there another solution so that your actual code isn't "polutted" with test-waiter stuff that obscures what it's actually doing?

this is reason enough to send all async code through a centralized library that can handle waiters while still having a high-level, fluent API.

- internals keep maintaining ordering guarantees (queue semantics) that nothing modern relies on
- Deprecate only the obviously-dead exports (`begin`, `end`, `join`, `bind`, `getCurrentRunLoop`) and keep the timer conveniences (`later`, `debounce`, `throttle`, `cancel`). This keeps backburner in every bundle to provide utilities that npm and the platform provide better, and keeps the implicit-settledness trap around.
- Adopt [RFC #957](https://github.com/emberjs/rfcs/pull/957)'s scheduler interface as the designated replacement, and make this deprecation part of that migration. This is a viable path (see _[Relationship to RFC #957](#relationship-to-rfc-957-render-aware-scheduler-interface)_), but it couples "stop shipping backburner" to "design, implement, and stabilize a new public scheduler" -- the deprecation shouldn't have to wait on the harder of the two projects, and most runloop usage migrates to the platform, not to a scheduler.
- Move the timer utilities to a standalone `@ember/timers` package with test-waiter integration built in. This is really just "bless ember-lifeline", which already exists -- the ecosystem doesn't need `ember-source` to own it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏿

- backburner ships in every app forever
- test-mode autorun errors keep being the first impression of Ember's testing story
- internals keep maintaining ordering guarantees (queue semantics) that nothing modern relies on
- Deprecate only the obviously-dead exports (`begin`, `end`, `join`, `bind`, `getCurrentRunLoop`) and keep the timer conveniences (`later`, `debounce`, `throttle`, `cancel`). This keeps backburner in every bundle to provide utilities that npm and the platform provide better, and keeps the implicit-settledness trap around.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏿

if one of the goals is separating ember's internal use of the runloop from the public interface, then:

  • making runloop just a thin wrapper as described and
  • renaming the backburner impl used in ember itself so that it's private

this provides near-zero API churn since the runloop becomes an optional utility package that you may or may not use at your discretion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-Proposed In the Proposed Stage

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants