Imports from @react-email/components break with import-in-the-middle about import-in-the-middle HOT 1 CLOSED

I've made some attempt to debug what is going on, though it's only been partially successful.

Replacing line: https://github.com/DataDog/import-in-the-middle/blob/c3c2c52c1915b47994af59d507c59029c1f1fae9/hook.js#L157

With:

      const isNodeModule = !(modFile.startsWith('.') || modFile.startsWith('/') || modFile.startsWith('file:'))
      const modUrl = isNodeModule
        ? new URL(require.resolve(modFile, {
          paths: [new URL(srcUrl).pathname]
        }), srcUrl).toString() 
        : new URL(modFile, srcUrl).toString()

This allows import-in-the-middle to get the correct url for submodule/child node_module library imports, however there is still an issue in that when it is processing those submodules import-in-the-middle fails to retrieve the submodule's exports. This results in the parent module being unable to re-export the submodule's exports as it does not know about the items being exported (the setters map for the submodule is returned as empty). The submodule then gets processed a second time after the parent has completed all its processing, this time properly picking up its own exports but it's too late at that point for the parent module to be informed of the child's exports. This then means that node throws errors that the parent "does not provide an export named 'XXX'" when it was one of the exports that the parent module was re-exporting from the submodule.

In terms of the isNodeModule test, I'm not sure if there are any other modFile exports likely to be seen, e.g. http: or deno:. If there are others that need to be treated like file/relative/absolute urls instead of using node resolution, that parameter should be updated to look for those too.

from import-in-the-middle.