Skip to content

always use an ApplicationInstance as the test owner - #1585

Open
NullVoxPopuli-ai-agent wants to merge 2 commits into
emberjs:masterfrom
NullVoxPopuli-ai-agent:nvp/owner-from-application
Open

NullVoxPopuli-ai-agent wants to merge 2 commits into
emberjs:masterfrom
NullVoxPopuli-ai-agent:nvp/owner-from-application

Conversation

@NullVoxPopuli-ai-agent

@NullVoxPopuli-ai-agent NullVoxPopuli-ai-agent commented Oct 9, 2026 •

Copy link
Copy Markdown

An alternative to #1584, from this question: can the copied Ember internals be deleted, not rewritten?

They can. The test owner is now always an ApplicationInstance.

Change

Before, the owner was a mock in two cases:

  • setResolver() without setApplication()
  • the resolver option of setupContext(), also when an application is set

The mock was an EmberObject with RegistryProxyMixin and ContainerProxyMixin, on a registry built by hand with private Ember API.

Now buildOwner() creates an Application that has only the resolver, and builds the instance from it. The application is destroyed together with the instance.

Deleted:

  • addon/src/-internal/build-registry.ts
  • the _emberTestHelpersMockOwner flag, and its special cases in setupRenderingContext() and getRootElement()
  • the imports from the container, runtime and views packages of @ember/-internals

@ember/test-helpers no longer calls EmberObject.extend() at import time. That call is what stops emberjs/ember.js#21673.

Breaking

  • The container of the mock owner had the old registry methods (container.register, container.resolve and others). They are gone.
  • The resolver-only owner now boots as an application instance. An event dispatcher is set up in setupContext(), not only in setupRenderingContext().

setResolver() and the resolver option stay, so engineResolverFor from ember-engines continues to work. I did not run the ember-engines tests.

Results

Test app in this repo, full suite:

Ember Result
5.12 (default) 563 of 563 pass
4.4 563 of 563 pass
canary 564 of 564 pass
release 559 of 559 pass, before the strict resolver tests were added

Strict resolver

tests/unit/strict-resolver-test.js uses ember-strict-application-resolver in the three ways an owner is built:

  • setResolver() with a StrictResolver and no application
  • the resolver option of setupContext()
  • setApplication() with a strict application

Each one gives an ApplicationInstance that resolves a service from modules, and render() works.

emberjs/ember.js at the commit of emberjs/ember.js#21673, full suite, with the dist of this branch in place of @ember/test-helpers 5.5.0:

Mode 5.5.0 This branch
default 9530 pass 9530 pass
ALL_DEPRECATIONS_ENABLED=true the page does not load 9530 pass
OVERRIDE_DEPRECATION_VERSION=15.0.0 the page does not load 8074 pass, 619 skipped

ember.js calls setApplication(), so its tests did not use the mock owner. Only the import-time EmberObject.extend() broke it.

🤖 Generated with Claude Code

NullVoxPopuli and others added 2 commits October 9, 2026 14:14
Without `setApplication`, or with the `resolver` option of
`setupContext`, the owner was a mock: an `EmberObject` with
`RegistryProxyMixin` and `ContainerProxyMixin`, on a registry built by
hand with private Ember API.

The owner is now an `ApplicationInstance`. An `Application` that has
only the resolver builds it, and that application is destroyed together
with the instance.

This removes `-internal/build-registry.ts`, the
`_emberTestHelpersMockOwner` flag and its two special cases, and the
imports from the `container`, `runtime` and `views` packages of
`@ember/-internals`. The module no longer calls
`EmberObject.extend()` at import time, which RFC 1117 deprecates.

Breaking: the old registry methods on the container of the mock owner
(`container.register` and others) are gone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`ember-strict-application-resolver` was a dependency of the test app
with no test. These tests use it in the three ways an owner is built:

- `setResolver()` with a `StrictResolver` and no application
- the `resolver` option of `setupContext()`
- `setApplication()` with a strict application

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@NullVoxPopuli
NullVoxPopuli marked this pull request as ready for review October 12, 2026 11:17
@NullVoxPopuli NullVoxPopuli changed the title Spike: always use an ApplicationInstance as the test owner always use an ApplicationInstance as the test owner Oct 12, 2026

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants