Resolver bugfixes

[mansona]

(Edits by @ef4:) This PR now encompasses several bug fixes. We made them all here together because their impact was inter-dependent -- fixing one revealed the others as failing tests.

• the node resolver now supports package.json exports by switching from the resolve package to require.resolve. This needed some finesse because require.resolve has some quirky behaviors.
• the emberVirtualPeerDeps can now find addons that are not directly resolvable from the app
• the webpack resolver was leaking state between requests and that is now fixed
• the active addons fallback now also supports the app as a target (since some people do resolve the app by name from addons)
• it was possible for requests to escape the moved package system when our node resolver and the prevailing packager's resolver disagreed. Now requests that we think should fail are forced to fail, allowing them to progress correctly down the rest of the fallbacks.

Original PR description follows:

Since we merged #1648 we can now have situations where our resolver requires you to rely on the exports field of dependencies to correctly locate a file. This is totally fine in our Webpack build, but with Vite and Esbuild you can have cases where we need to go through our node resolver to find something and it fails because resolve doesn't yet support exports

This PR removes the need for resolve in our node resolver 👍 I've marked this PR as breaking because it is possible that it could change behaviour 🤔

[ef4]

The goal here is fine, the question is whether you can get all the tests to pass without the resolvableExtensions.

[patricklx]

it could to both then?
the resolvableExtensions should only be a problem for the real app files.
all other package (addons) files should already be converted to .js files, right?

[patricklx]

like here: https://github.com/embroider-build/embroider/pull/1695/files#diff-61967680c203e14cb9a3b2c252caca7d6b0ee9b285991dba6b728f6c54112a12R294

[ef4]

In 000d1ea I fixed a nasty bug, and it revealed other problems which probably can't be fixed without doing this PR, which is why I added the commit to here.

Then I was investigating the test failures and found a very annoying issue, related to the fact that pnpm extends NODE_PATH in bin shims, and require.resolve always checks NODE_PATH even when you override paths. So we're finding extra stuff by mistake, which leads to very confusing downstream failures.

[patricklx]

Ah, i fixed the issues you have here: #1695
But maybe i also fixed the in a wrong way

8c9be4d
f675826
d53a80d

[ef4]

Next issue here is that require.resolve('.', { paths }) doesn't actually do the same thing that normal require.resolve('.') does. We'll need a better strategy for self-imports.

Probably we can expand our notions of canResolveFrom so that for every addon we know a safe "outside" vantage point to resolve it from. For the app we can construct such a place if necessary, using symlinks.

[ef4]

This is finally all passing!

I don't think this actually ended up breaking. I'm going to relabel it bugfix.

[mansona]

@ef4 if this wasn't actually breaking how do you feel about backporting this to stable? 🤔 this is required for v2 addons to enable type: module (if they want to)

[ef4]

I'd want to hear from some large-ish apps that confirmed unstable is working for them. It's not unlikely that this does break somebody, given the wide range of legacy behaviors we're trying to support. So we have to weigh the risk of spending several days investigating bugs reports vs the benefit of accelerating getting these changes out.