GeezerVison

The notable-change PRs with changes that should be highlighted in changelogs. label has been added by @mcollina.

Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment.

This was suggested before in #39147. Has anything changed since then?

This was suggested before in #39147. Has anything changed since then?

I think it is less controversial now. Everybody migrating to ESM needs to figure this out and it requires way too many steps to get those values.

This may be of no concern, but Bun appears to use import.meta.dir and import.meta.path for these values: https://bun.sh/docs/api/import-meta idk if that's relevant tho. 🤷‍♂️

Everybody migrating to ESM needs to figure this out and it requires way too many steps to get those values.

Why do you need paths though? It shouldn't be necessary, URL should get you covered.

Why do you need paths though? It shouldn't be necessary, URL should get you covered.

Most APIs from fs and path do not work well with URLs. Reading files relative to the current one is something everybody does all the time for all sorts of purposes. Currently, it takes quite a few lines of code to get the path for a file in the same directory:

import { fileURLToPath } from 'url'
import { dirname, join } from 'path'

const __dirname = dirname(url.fileURLToPath(import.meta.url))
const toAccess = join(__dirname, 'another_file')

Most APIs from fs

That's wrong I think, all node:fs APIs works with either. If you see issues with node:fs and URL, please open an issue, that'd be a bug.

and path

That's kinda obvious, node:path is for paths, not URLs.

Reading files relative to the current one is something everybody does all the time for all sorts of purposes.

That's my point, you should be using URL for that. The equivalent to your code snippet would be:

const toAccess = new URL('./another_file', import.meta.url);

I think this goes in the wrong direction. I'm happy to be proven wrong, but I guess there's also an ideological problem: I think using paths in ESM is a faux-pas, if one goes ESM, they should let paths be a relic of the past, and embrace URLs. I can see it can certainly be useful to have the proposed properties to convert a CJS module to ESM, but someone writing ESM from scratch should never need it, and it would be confusing to add something that works only on file: protocol, when I would prefer to see Node.js go in the direction of being more protocol agnostic.

We should also consider if it will help the adoption of ESM and make migration easier / less painful.
even if there is an ideological issue - it is not very pragmatic to only provide a solution for "someone writing ESM from scratch".
even if one can argue it will never be needed, avoiding such utilities/helpers because they seem redundant can have a negative effect on the ecosystem.

if one goes ESM, they should let paths be a relic of the past, and embrace URLs.

It's like a muscle memory even can trace from python. It can avoid many mental burden from using esm, this is my mosted missed feature in esm.

Also many people trapped on this. lots of libs goto full esm have this info everywhere.

It's a good move in the long run, and way friendly for users back then when only cjs exists.

I will share some my work experience, we used js almost everywhere, some are cjs, some are esm. When it comes to script job in CI and linux server, it's always have been cjs module. because __dirname and __filename used everywhere just like python. Esm equivalence is way verbose and less instinctive.

@aduh95 The vast majority of the modules on npm only accept paths, not URLs. Therefore it adds quite a bit of a mental burden to do that. The recommendation you have is for all modules on NPM to start accepting file:// URLs as well as paths, or even only URLs. I don't think that's feasible.

Even modules that went all-in on ESM only use paths everywhere and not URLs, as an example take a look at https://vitest.dev/guide/#workspaces-support.

Overall I think adding __filename and __dirname will help the adoption of ESM.