Fix resolution of lib/register.js when using multiple loaders

[nwalters512]

This PR fixes the issue that's been described at length in the following issues:

• import hook incompatible with tsx getsentry/sentry-javascript#12011
• import-in-the-middle causes exception when creating ERR_MODULE_NOT_FOUND message node#52987

To summarize, import-in-the-middle can cause problems in the following situation:

• A Node core module (node:*) is imported
• Another loader is added before import-in-the-middle
• That loader tries to resolve files that don't exist on disk

In practice, this occurs when using import-in-the-middle with code that's being executed with tsx. tsx will try to resolve .js files by also looking for the same file path but with a .ts extension. In many cases, including the synthetic code that import-in-the-middle generates to import lib/register.js, such a corresponding .ts file does not exist.

The actual error arises from Node, which assumes that parentURL will always be a file:// URL when constructing an ERR_MODULE_NOT_FOUND error; see the linked issue above. In the above scenario, the .ts file that is being resolved does not exist, so such an error is created, and parentURL === 'node:*', so the failing case is triggered. It seems like Node is receptive to changing that behavior, but in the meantime, I was hoping to land this patch so that one doesn't have to wait for and upgrade to a new version of Node.

The fix works by short-circuiting the resolution of lib/register.js so that the other loader (that tries to resolve non-existent paths) is never tried.

[GeoffreyBooth]

This will only work if specifier is an absolute URL. It hasn’t been resolved yet, so this is the string passed to import.

What is the approach being pursued here? When IITM itself is being registered, short-circuit the chains? But this is ITTM, so this condition would only ever be true if ITTM is registered twice?

[nwalters512]

Double-check what iitmURL actually refers to. It is not hook.js; it is lib/register.js, which is imported from generated code here:

https://github.com/DataDog/import-in-the-middle/blob/00b01fff1f5b69dd25e307593ec54d1d8abb4844/hook.js#L302

Note that in this case, the specifier templated into the generated code and passed to import is an absolute file:// URL.

[nwalters512]

For slightly more context, the actual problem stems from the fact that import-in-the-middle ends up generating source for node:* imports via load(), and that this code imports absolute file URLs (lib/register.js). That's how we end up in a situation where parentURL is node:* and specifier is an absolute file:// URL.

[bengl]

@nwalters512 This LGTM but there are now conflicts. Can you rebase plz?

[nwalters512]

@bengl done ✅