Repository: node
Issue: Importing module on filesystem from data URL throws `TypeError: Invalid URL` / `ERR_UNSUPPORTED_RESOLVE_REQUEST:  Invalid relative URL or base scheme is not hierarchical.`
Labels: esm,loaders

### Version

v20.11.1

### Platform

Linux devbox.home.arpa 6.1.0-16-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12) x86_64 GNU/Linux

### Subsystem

_No response_

### What steps will reproduce the bug?

Creating an `index.mjs` file with the following contents and running it with `node index.mjs` causes nodejs to be unable to resolve the `foo` module when running in base-64 land.

```js
import fsp from 'fs/promises';

// create `foo` module
await fsp.mkdir('./node_modules/foo', { recursive: true });
await fsp.writeFile(
    './node_modules/foo/package.json',
    JSON.stringify({
        name: 'foo',
        exports: {
            '.': './index.mjs',
        },
    })
);

// build base64 url just importing `foo`
const importName = `foo`;
const unencoded = `await import("${importName}")`;
const encoded = Buffer.from(unencoded).toString('base64');
const url = `data:text/javascript;base64,${encoded}`;

// import that base 64 url
await import(url);

```

This seems to be because to resolve `foo` we try to load `package.json`'s, but it seems like we're trying to do it *from* the data URL, which can't work.

### How often does it reproduce? Is there a required condition?

You should run this code somewhere where it's safe to create a new `node_modules`.

Running the code always produces the same result on macOS and Linux. Untested on Windows.

### What is the expected behavior? Why is that the expected behavior?

Either:

- nodejs should error with a clear description of the problem, rather than throw an internal error from URL 
- (or) nodejs should allow importing from the data URL by using the context of the base64 module's parent for imports called from the base64 module

I think either this shouldn't try to do this and should error explicitly that it's not supported, or it should work if it's within scope/spec. I'd argue an internal error saying the URL is invalid (when both package.json and the data URL are valid) is confusing here for most nodejs developers.

### What do you see instead?

```
node:internal/url:775
    this.#updateContext(bindingUrl.parse(input, base));
                                   ^

TypeError: Invalid URL
    at new URL (node:internal/url:775:36)
    at getPackageScopeConfig (node:internal/modules/esm/package_config:29:24)
    at packageResolve (node:internal/modules/esm/resolve:807:25)
    at moduleResolve (node:internal/modules/esm/resolve:910:20)
    at defaultResolve (node:internal/modules/esm/resolve:1130:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:396:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:365:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:240:38)
    at ModuleLoader.import (node:internal/modules/esm/loader:328:34)
    at importModuleDynamically (node:internal/modules/esm/translators:158:35) {
  code: 'ERR_INVALID_URL',
  input: './package.json',
  base: 'data:text/javascript;base64,YXdhaXQgaW1wb3J0KCJmb28iKQ=='
}

Node.js v20.11.1
```

### Additional information

Potentially related to #51444 and #38714

Potentially related to subsystems:

@nodejs/loaders @nodejs/modules

Workaround: https://github.com/benjamingwynn/data-import-fix