feat: import.meta.resolve()

[bartlomieju]

Opening for a discussion purposes.

// meta.js
console.log("Resolving ./foo.js", import.meta.resolve("./foo.js"));

$ deno run meta.js
Resolving ./foo.js file:///Users/ib/dev/deno/foo.js
Resolving ./foo.js from ./bar.js file:///Users/ib/dev/deno/foo.js

@guybedford I'm a bit surprised in Node's behavior:

$ node --experimental-import-meta-resolve meta.mjs
I am file:///Users/ib/dev/deno/meta.mjs [Object: null prototype] {
  resolve: [AsyncFunction: resolve],
  url: 'file:///Users/ib/dev/deno/meta.mjs'
}
node:internal/errors:466
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/ib/dev/deno/foo.js' imported from /Users/ib/dev/deno/meta.mjs
    at new NodeError (node:internal/errors:377:5)
    at finalizeResolution (node:internal/modules/esm/resolve:405:11)
    at moduleResolve (node:internal/modules/esm/resolve:966:10)
    at defaultResolve (node:internal/modules/esm/resolve:1174:11)
    at ESMLoader.resolve (node:internal/modules/esm/loader:605:30)
    at Object.resolve (node:internal/modules/esm/initialize_import_meta:15:26)
    at file:///Users/ib/dev/deno/meta.mjs:2:53
    at ModuleJob.run (node:internal/modules/esm/module_job:198:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:409:24) {
  code: 'ERR_MODULE_NOT_FOUND'
}

Node.js v18.1.0

I would have thought that this function is for pure resolution and it won't touch file system to check for the existence of a specifier we're trying to resolve.

Closes #7296

[lucacasonato]

This should be sync. HTML spec is sync.

[bartlomieju]

This should be sync. HTML spec is sync.

That's fine for me, I'll rework the PR after fixing main branch

[bartlomieju]

@lucacasonato I've reworked it to be sync, PTAL

[guybedford]

@bartlomieju the reason for the Node.js behaviour is because Node.js will still apply the realpath algorithm to resolutions, which in turn throws. I agree it's not ideal - one thing we could do is catch any not found errors and rethrow them at load time rather. Perhaps realpathing should be handled more like redirects as well in being the response URL not the request URL, to get even more alignment with the web, despite the pains of that in double instancing. I can possibly try to push those two changes through Node.js process.

[bartlomieju]

That makes it clear now, thanks for a thorough explanation. Since it already diverges from the spec by returning a promise I think it's okay for the behavior to stay as is, but would be great to have it documented.

[guybedford]

We are actively working on aligning on a sync resolver, it just will take some time.

[guybedford]

What happens when the referrer is an invalid URL? That might not be tested for the core resolver?

[bartlomieju]

loader.resolve() raises an error that is forwarded to JS

[lucacasonato]

Can you add a test? For example trying to resolve an invalid URL.

[guybedford]

To be transparent there is still some uncertainty about the second argument - whatwg/html#8074 (comment).

[bartlomieju]

To be transparent there is still some uncertainty about the second argument - whatwg/html#8074 (comment).

I think it would be safer for us, to only support the first argument for now since it's a living standard right now.

[bartlomieju]

I've reverted addition of the second argument since it is not yet specced. @lucacasonato please review.

[lucacasonato]

LGTM