Add `import.meta.directory` and `import.meta.file` properties

[SetTrend]

What is the problem this feature will solve?

Currently, import.meta.url gets the current file's absolute file path in URL format. This format cannot be used with node:path for creating absolute file paths.

The proposed additional properties will provide the current file's file path details in a format that can be used with node:path.

What is the feature you are proposing to solve the problem?

import.meta should provide the following additional properties:

1. directory
2. file

Example

Given the following absolute file path (on Windows):

C:\user\repos\mine\main.js

… import.meta would provide the following properties:

{
  "directory"  : "C:\\user\\repos\\mine\\"
  "file" : "main.js"
  "url"  : "file:///C:/user/repos/mine/main.js"
}

[sindresorhus]

dir

Should be directory. Lets not abbreviate for the sake of it.

[SetTrend]

Absolutely. I amended OP and title accordingly.

[aduh95]

What would we use as values when the module is loaded from outside of the FS? E.g. from the network or from a custom loader.

[SetTrend]

One option may be to define both as : string | nothing.

[aduh95]

I’m not sure it’s worth adding something that you can rely upon because it may not be defined. Maybe we should ask why import.meta.url and the URL API doesn’t work for you today. You say in the OP that you’d like an absolute file path, why? What’s your use case, if I may ask?

[SetTrend]

Sure.

Webpack, for instance, requires an absolute path. This requirement brought me to the idea that something intrinsic, important is missing.

Multi-threaded applications or libraries might also prefer to work with absolute paths.

[aduh95]

That looks like an issue on Webpack side rather than Node.js. Did you try reaching out to them? In the mean time, you can use fileURLToPath(import.meta.url) when you need a path, but IMO not supporting file: URL should be considered a bug.
I suggest we close this issue for now, we can reopen it a compelling use case arises, and we find a compromise for non-FS modules, and other JS runtimes show interest. Wdyt?

[SetTrend]

I have a different perspective. Writing desktop applications or libraries will not be able to use import.meta.url. They need to be presented with a file system path.

[aduh95]

I have a different perspective. Writing desktop applications or libraries will not be able to use import.meta.url. They need to be presented with a file system path.

Why is that? What is it that you can do with an absolute path that you can’t do with a file: URL?

[SetTrend]

After further digging into the Webpack issue I'm facing, I'm not quite sure if it isn't a Webpack issue after all.

However, from my observation I noticed that the path library yields inconsistent output:

import * as path from 'node:path';

const url = import.meta.url;
const dir = path.dirname(import.meta.url);
const newdir = path.join(path.dirname(import.meta.url), 'dust');

console.log(`url: ${url}`);
console.log(`dir: ${dir}`);
console.log(`newdir: ${newdir}`);

… yields:

url: file:///D:/Documents/Visual%20Studio-Projekte/HTML/MyProject.js/webpack/webpack.config.mjs
dir: file:///D:/Documents/Visual%20Studio-Projekte/HTML/MyProject.js/webpack
newdir: file:\D:\Documents\Visual%20Studio-Projekte\HTML\MyProject.js\webpack\dust

path.join() converts the path format while path.dirname() doesn't. The two different formats lead to ambiguous results, thereby rendering manual path operations error prone.