esm: fix base URL for network imports

[bmeck]

Per the PR text this kind of explains what is going on:

  /**
   * ...
   * 
   * In WHATWG HTTP spec for ESM the cache key is the non-I/O bound
   * synchronous resolution using only string operations
   *   ~= resolveImportMap(new URL(specifier, importerHREF))
   * 
   * The url used for subsequent resolution is the response URL after
   * all redirects have been resolved.
   * 
   * https://example.com/foo redirecting to https://example.com/bar
   * would have a cache key of https://example.com/foo and baseURL
   * of https://example.com/bar
   * 
   * ...
   */

Likely this should be a bigger refactor because callbackMap is becoming spaghetti but that should/can be punted for now.

This is 1/2 of the issues we have seen with HTTPS CDNs for ESM and is a partial fix for #42098 .

I would note that the URL mentioned in the corresponding issue continues to fail even with this and #42119 because it redirects to an absolute URL with a 404:

302 https://unpkg.com/uuid?module ->
200 https://unpkg.com/uuid@8.3.2/dist/esm-node/index.js?module -> (this is where the PR fixes apply in both PRs)
200 https://unpkg.com/uuid@8.3.2/dist/esm-node/rng.js?module ->
404 https://unpkg.com/crypto@latest?module

Before this PR the base URL used for resolving ./rng.js was incorrectly using the cache key of the module https://unpkg.com/uuid?module. Per WHATWG this should actually be changed to https://unpkg.com/uuid@8.3.2/dist/esm-node/index.js?module

Set base URL to referencing script's base URL.

And WHATWG:

It is intentional that the module map is keyed by the request URL, whereas the base URL for the module script is set to the response URL. The former is used to deduplicate fetches, while the latter is used for URL resolution.

After both PRs the behavior in Node matches the browser: https://jsfiddle.net/n8cwL4bm/

[nodejs-github-bot]

Review requested:

• @nodejs/modules

[bmeck]

this PR depends on #42119

[guybedford]

Looks good, if we move to multiple loaders in the same context we might have to reconsider the approach though.

Agreed it would be nice to clean up the callbackMap for a better approach at some point.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/42820/

[JakobJingleheimer]

Thanks for cranking this out so fast! 🙌 This was a bit of a doozy to investigate and noodle.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/42839/

[bmeck]

had to rebase due to test failure, going to land in after CI and a small wait

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/42870/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/42876/

[bmeck]

CI tests look to be flaky per @nodejs/reliability, running last CI then merging if no other tests fail

[bmeck]

Landed in acc11c9

[danielleadams]

Waiting on backport: #42726