Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@ember/test-helpers is trying to import from ember-testing but that is not one of its explicit dependencies #2096

Open
simonihmig opened this issue Sep 6, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@simonihmig
Copy link
Collaborator

Also reported here, but the root cause seems to be in Embroider: emberjs/ember-test-helpers#1505

Context:

I was debugging what is going in Embroider's module resolver, my findings:

As said, under Embroider optimized this is working fine. The request for ember-testing is rewritten in handleRenaming to ember-source/ember-testing/index.js, which seems to do the trick:

Bildschirmfoto 2024-09-06 um 09 55 29

The same is not happening under safe mode, it doesn't have that full list of renameModules that optimized has:

Bildschirmfoto 2024-09-06 um 09 58 48

But I assume that is expected?

An import request for ember-testing is handled here, as the specifier matches what @ember/test-helpers has declared as externals in its package.json. However, there are follow-up requests for deeper module paths like ember-testing/lib/test/pending_request, where isExplicitlyExternal() is returning false, as it checks for equality (by using .includes()):

Bildschirmfoto 2024-09-06 um 10 38 44

In that case, that request is running then into throwing the exception here.

When upgrading to latest @embroider/core (that has emberjs/ember-test-helpers#1486), things are working as the resolver is having ember-testing in emberVirtualPackages, so exits early here.

So upgrading is a fix for this situation. But it seems to me isExplicitlyExternal is not handling this case correctly. I am naively thinking, that a fix could be as simple as replacing .includes() with .startsWith() here.?

Before going further and filing a PR, I wanted to make sure this makes sense and my observations and assumptions are correct here!

Would still require users to upgrade to latest core though! 🙃

@simonihmig simonihmig added the bug Something isn't working label Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant