import.meta.resolve(…) is documented to return a string, but returns a URL object

[lgarron]

Version

v20.6.1

Platform

Darwin Germain.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 arm64

Subsystem

No response

What steps will reproduce the bug?

https://nodejs.org/api/esm.html#importmetaresolvespecifier states:

Returns: <string> The absolute (file:) URL string for the resolved module.

The following prints a URL object:

echo "console.log(process.versions.node); console.log(import.meta.resolve('./rel'));" > /tmp/test.mjs
node /tmp/test.mjs

(import.meta.resolve('./rel')) instanceof URL also evaluates to true.)

How often does it reproduce? Is there a required condition?

N/A

What is the expected behavior? Why is that the expected behavior?

The documentation and the behaviour match.

All browsers and deno return a string, and it sounds like bun would also prefer this. I don't feel strongly myself, although I feel matching browsers would be less surprising if I was learning the API from scratch — it's always possible translate between formats if needed, but the ecosystem benefits from consistent type signatures in several ways.

See #48994 for a related discussion about API ergonomics.

What do you see instead?

The documentation and behaviour mismatch.

Additional information

No response

[GeoffreyBooth]

Yes, this is a bug, thank you for flagging it. import.meta.resolve should return an URL string, similar to import.meta.url. cc @guybedford @aduh95 @nodejs/loaders

[jimmywarting]

I think it should match deno / browsers behavior and return a url string.

[JakobJingleheimer]

Ugh much as it pains me, it is spec'ed to return a url string. Not what anybody wanted, but it is what it is. Maaaybe something else coming.

[jimmywarting]

all the fuzz in #48994 is really only about node:fs only supporting URL instances. and /paths (no fileUrl string path)
that is what they are bothered about.
if we did not have node:fs, or if the filesystem was so inherity bad that it allowed folks to create files and directory with bad names, then nobody would have created #48994 and nobody would complain about it. so imo i think there is nothing wrong with it returning a string. perhaps maybe, just maybe we could improve node:fs to work with fileUrl strings instead somehow?

Personally, I would consider switching away from using node:fs if Deno, Bun, and Node.js could reach a consensus on implementing the WHATWG/fs and File System Access API. This would promote more cross-compatibility in code, eliminate the complexity of having to deal with paths, URLs, or URL strings, and ensure consistent functionality across different environments, including the browser, without relying on additional dependencies. While it might not be as developer-friendly, it would provide a consistent and dependency-free solution.

[GeoffreyBooth]

Personally, I would consider switching away from using node:fs if Deno, Bun, and Node.js could reach a consensus on implementing the WHATWG/fs and File System Access API.

Sure, do you want to open an issue on https://github.com/wintercg/proposal-common-minimum-api/ to propose something? Or to just start a discussion.

[jimmywarting]

Sure, do you want to open an issue on https://github.com/wintercg/proposal-common-minimum-api/ to propose something? Or to just start a discussion.

Already did: wintercg/proposal-minimum-common-api#5

[lgarron]

Looking good on nightly!

> ./node /tmp/test.mjs
21.0.0-nightly202309229718a9465c
file:///private/tmp/rel

[lgarron]

Looking good on nightly!

Also looking good inv20.8.0!

> echo "console.log(process.versions.node); console.log(import.meta.resolve('./rel'));" > /tmp/test.mjs
> node /tmp/test.mjs
20.8.0
file:///private/tmp/rel