GeezerVison

If this did happen to land, I'd suggest it would be a good idea to contribute an eslint rule that flags uses and recommends the equivalent import.meta.url uses instead.

If these are legacy, that implies a deprecation/transition period right? Would migrating a file from cjs to esm not already be that transition? People will just use these and then we'll have to support them forever even though they're bad.

To be clear, legacy status does not imply eventual deprecation.

As an alternative or in parallel, I think we should also improve the documentation at https://nodejs.org/dist/latest-v16.x/docs/api/esm.html#esm_no_filename_or_dirname or https://nodejs.org/dist/latest-v16.x/docs/api/esm.html#esm_import_meta_url, by giving examples of how common use cases can be done with import.meta.url

I was hoping that one day we will get rid of CJS legacy aka __filename, __dirname, but yet it's coming back 🥶

Do we have a clear problem with including these? It won't cause a static unrecoverable error if these values are used.

My main concern is this just adds 1 more code migration, though it is incremental. Adding them to import.meta still requires that code be updated so that they can be used. It also still means that examples are not shared between CJS and ESM:

// __dirname is a ReferenceError here
fs.readFile(import.meta.__dirname);

// import.meta is a SyntaxError here
fs.readFile(__dirname);

I think an approach that allows both CJS and ESM to share the code would be somewhat preferable to this, but I don't have any major concerns w/ these being added except that they would be wasted compute for any module not using them and using import.meta.url (and vice versa).

given the controversy here and given that I'm not 100% bought in to this idea either, I'm going to go ahead and close this :-)