new URL('.', import.meta.url).pathname produces erroneous path on Windows 10

[aral]

• Version: v14.16.0
• Platform: Microsoft Windows NT 10.0.19041.0 x64
• Subsystem: module.import

What steps will reproduce the bug?

const __dirname = new URL('.', import.meta.url).pathname
console.log(__dirname)

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

Always.

What is the expected behavior?

On Linux and macOS, the snippet of code, above, produces the desired outcome, which is to emulate the __dirname value that exists in CommonJS in a module in an ECMAScript Modules (ESM) project.

If, for example, the above snippet of code is run from index.js in /home/aral/sandbox/dirname-test, the path that is created is the following (and correct):

/home/aral/sandbox/dirname-test/

It should, similarly, create a correct path on Windows.

What do you see instead?

The path that is created in Windows is incorrect.

If, for example, the above snippet of code is run from index.js in C:\Users\aral\sandbox\dirname-test, the path that is created is the following (and is wrong):

/C:/Users/aral/sandbox/dirname-test/

The correct output should be:

C:\Users\aral\sandbox\dirname-test\

Additional information

This updated workaround, based on @devsnek’s reponse, should behave properly across platforms:

import { fileURLToPath } from 'url'
const __dirname = fileURLToPath(new URL('.', import.meta.url))
console.log(__dirname)

(However, the original snippet should also behave correctly on all platforms and doesn’t.)

[devsnek]

This is the correct output. URLs are not paths. You should convert the url to a path and then perform resolution using that: https://nodejs.org/api/url.html#url_url_fileurltopath_url

[aral]

@devsnek Thank you for the clarification, so would you say the following is a canonical equivalent for __dirname in ESM projects (or would you recommend something better? The snippet in question works well in my tests):

import { fileURLToPath } from 'url'
const __dirname = fileURLToPath(new URL('.', import.meta.url))

Also, as a follow-up, was there a reason why this equivalent for __dirname, as well as a require function via createRequire() is not included in Node proper? I find myself having to define these nearly every time I port a CommonJS module to ESM and I feel it would help, greatly, if they were (unless there are overwhelming reasons not to). Would you be open to a separate issue (feature request) for this?

Thanks :)

[Jack-Works]

import { fileURLToPath } from 'url'
const __dirname = fileURLToPath(new URL('.', import.meta.url))
console.log(__dirname)

Yes, I agree this is the correct way to do things. But many developers don't aware of this because they use *nix systems and this creates pain for Windows users.

An example:

Library secp256k1 uses new URL(...).pathname and pass it to readFileSync which is error on Windows.

https://github.com/bitcoinjs/tiny-secp256k1/blob/master/src_ts/wasm_path.ts

Library endo.js uses this pattern too:

https://github.com/endojs/endo/blob/fba461f2786e1f9569c1bfb839e03d45cee7d2a6/packages/compartment-mapper/src/node-powers.js#L18

I think it will be better if Node fs module can accept this kind of path /C:/Users/Someone/... as a valid path, this will create less pain for windows users.