Skip to content

Pick legacy-inspector-support entry by ember-source version#320

Merged
NullVoxPopuli merged 1 commit intoember-cli:nvp/its-vite-timefrom
NullVoxPopuli-ai-agent:fix/inspector-support-macro
Apr 19, 2026
Merged

Pick legacy-inspector-support entry by ember-source version#320
NullVoxPopuli merged 1 commit intoember-cli:nvp/its-vite-timefrom
NullVoxPopuli-ai-agent:fix/inspector-support-macro

Conversation

@NullVoxPopuli-ai-agent
Copy link
Copy Markdown

Summary

Fixes the min-supported try-scenario on #317:

[vite]: Rollup failed to resolve import "@ember/enumerable/mutable"
from ".../@embroider/legacy-inspector-support/src/modules-4-12.js"

@embroider/legacy-inspector-support ships three entry points, each paired with its own modules-*.js tailored to a different ember-source range:

entry target notable imports
ember-source-3.28 Ember < 4.8 legacy @ember/-internals/runtime/lib/mixins/mutable_enumerable
ember-source-4.8 Ember >= 4.8 < 4.12 @ember/enumerable/mutable
ember-source-4.12 Ember >= 4.12 @ember/enumerable/mutable + @ember/owner

test-app/app/app.js was hard-coded to ember-source-4.12, so the min-supported scenario (which installs ember-source: ~4.2.0) ended up pulling in modules-4-12.js@ember/enumerable/mutable, which doesn't exist in Ember 4.2. Rollup couldn't resolve it and the build failed.

Use macroCondition + dependencySatisfies + importSync from @embroider/macros (already a devDependency) to select the entry at build time based on the installed ember-source version:

let setupInspector;
if (macroCondition(dependencySatisfies('ember-source', '>= 4.12.0'))) {
  setupInspector = importSync('@embroider/legacy-inspector-support/ember-source-4.12').default;
} else if (macroCondition(dependencySatisfies('ember-source', '>= 4.8.0'))) {
  setupInspector = importSync('@embroider/legacy-inspector-support/ember-source-4.8').default;
} else {
  setupInspector = importSync('@embroider/legacy-inspector-support/ember-source-3.28').default;
}

The macros compile the untaken branches away, so each try scenario only brings the import graph that its installed ember-source can satisfy.

Test plan

  • min-supported (ember-source ~4.2.0) goes green — picks the 3.28 entry
  • ember-lts-5.12 / ember-lts-6.4 / ember-latest / ember-beta / ember-alpha still pick the 4.12 entry and remain green
  • ember-lts-4.12 picks the 4.12 entry — note: that scenario has a separate, unrelated failure (Rollup failed to resolve import "require" in @ember/test-helpers/-internal/build-registry.js) that this PR does not address

🤖 Generated with Claude Code

The min-supported try-scenario was failing with:

    [vite]: Rollup failed to resolve import "@ember/enumerable/mutable"
    from ".../@embroider/legacy-inspector-support/src/modules-4-12.js"

`@embroider/legacy-inspector-support` ships three entry points sharded by
ember-source range:
  - ember-source-3.28  → Ember < 4.8   (uses legacy mutable-enumerable path)
  - ember-source-4.8   → Ember 4.8–4.11 (adds @ember/enumerable/mutable)
  - ember-source-4.12  → Ember >= 4.12 (also adds @ember/owner)

test-app/app/app.js was hard-coded to the 4.12 entry, so the min-supported
scenario (ember-source ~4.2.0) pulled in modules-4-12.js, which imports
`@ember/enumerable/mutable` — a module that doesn't exist in Ember 4.2.

Use macroCondition + dependencySatisfies + importSync from @embroider/macros
to pick the right entry at build time based on the installed ember-source.
The macros compile the untaken branches away, so each try scenario only
pulls in the import graph it can actually resolve.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@NullVoxPopuli NullVoxPopuli merged commit 98674b0 into ember-cli:nvp/its-vite-time Apr 19, 2026
18 of 20 checks passed
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