import.meta.filename and import.meta.dirname

[mcollina]

One of the most annoying things in the ESM implementation in Node.js is the lack of __filename and __dirname to work with paths from ESM files.

I would recommend we specify import.meta.dirname and import.meta.filename as optional shared metadata, returning the local paths in the filesystem as strings (and not file:// URLs).

For more context: nodejs/node#48740

[GeoffreyBooth]

I think the desire for Node users at least would be for these two new methods to return the same strings that Node users are familiar with from CommonJS __filename and __dirname, values like:

• __filename: /tmp/test/file.js
• __dirname: /tmp/test

Note the lack of trailing slash on __dirname. That’s probably something we should standardize.

We also should standardize what import.meta.dirname and import.meta.filename are for modules that aren’t loaded from the filesystem, such as modules imported from an HTTPS URL. Should they be undefined? Empty strings? Getters that throw?

For reference:

• Bun has import.meta.path and import.meta.dir: https://bun.sh/docs/api/import-meta.

  • import.meta.path behaves identically to __filename, returning a full path including filename.

  • import.meta.dir behaves identically to __dirname, returning a full path with no trailing slash.

  • Bun also has import.meta.file that returns only the filename, so like file.js rather than /tmp/test/file.js.

• Deno has neither: https://deno.land/manual/runtime/import_meta_api

• Node has neither: esm: add import.meta.dirname and import.meta.filename nodejs/node#48740

[jasnell]

My preference would be for runtimes (and wintercg) to...

• Adopt the properties as implemented currently by bun. https://bun.sh/docs/api/import-meta
• Define them such that they are optional and only relevant to runtimes that map modules to an underlying filesystem model (virtual or otherwise). Runtimes that do not map modules to an underlying filesystem model (or modules that are loaded from data: or https: paths, for instance) would simply omit these properties, relying instead on import.meta.url.

[GeoffreyBooth]

Personally I think Bun can keep shipping import.meta.dir and import.meta.file like they do now, but the WinterCG spec defines import.meta.dirname and import.meta.filename to match Node’s __dirname and __filename. Bun can always support all four properties if they wish; fortunately they didn’t choose names that clash. I feel like there’s astronomically more code out there, and more developers, expecting the __filename and __dirname semantics.

[mcollina]

The whole reason to add those for Node.js familiarity with __dirname and __filename.

[lucacasonato]

Deno's stance on this is that we are generally opposed, because it results in different observable behaviour from within a module, depending on if it is served in HTTP (or other remote protocol), or the file system.

If the primary use-case is to reference assets relative to a given module, then a developer may use import.meta.file (which works locally), then publish to a CDN, and then the same code will not work anymore because remote modules have a https: specifier in the import.meta.url (and as such no import.meta.file).

Instead, developers should use import.meta.resolve, which returns a URL, and then do conditional logic based on the scheme of that URL. For example for file:// use readFile() (which is easy because readFile supports URLs), and for https:// use fetch().

Are there other use-cases that do not fall into the above class?

[pi0]

What if we conditionally expose import.meta.{filename,dirname} for modules that live in the filesystem? So for remote URLs, only depend on import.meta.url and avoid undesirable conditions?

Als a relevant issue since dealing with platform filesystem paths and url, will we keep Windows paths unnormalized with a backward slash for normalize to forward slashes? For context for unjs/mlly ESM utils, we make use of unjs/pathe which ensures normalized paths. It made life much easier to avoid edge-case conditions and in node

File URL requires platform normalization. The Node.js methods pathToFileURL, fileURLToPath are nor convenient to be used every place when depending on import.meta.url for fs paths. A normalized import.meta.dirname/import.meta.filename can make life much easier for developers.

[lucacasonato]

My concern is primarily one of portability. If a developer relies on import.meta.filename, or import.meta.dirname and this works locally (because the module is on FS), and then they publish their module to a HTTP server and then it is imported as a https: module, then the code stops working. This breaks portability.

This is not just a concern for runtimes like Deno where local development happens on file URLs, and published modules are http URLs, but also for bundlers, and even node with custom loaders. In all of these cases, code may work in one scenario, and break in another.

This is a portability hazard -- we should not add more portability hazards, especially in a standards venue explicit created to promote portability.

[GeoffreyBooth]

Personally I think Bun can keep shipping import.meta.dir and import.meta.file like they do now, but the WinterCG spec defines import.meta.dirname and import.meta.filename to match Node’s __dirname and __filename.

I missed that Bun also has import.meta.path, which matches __filename. So if we want to just run with the names Bun has chosen, we could do import.meta.path for __filename and import.meta.dir for __dirname. Personally I feel like we should still ship import.meta.filename and import.meta.dirname because there are many more developers familiar with those names, but we can also ship both where import.meta.path and import.meta.filename are the same value, and import.meta.dir and import.meta.dirname are the same value.

[jasnell]

What I would ask is that if Node.js and Deno want to ship import.meta.dir, import.meta.file, and import.meta.path, they collaborate on a spec document that defines the semantics clearly and independently of the specific runtime implementations. I would ask also that it deals with the portability footgun that @lucacasonato describes such that developers who are following the specs know what they may be getting themselves into should they use these properties.

Absent such a spec, these properties should be namespaced, e.g. import.meta.node.filename and import.meta.node.dirname, etc.

[GeoffreyBooth]

My concern is primarily one of portability. If a developer relies on import.meta.filename, or import.meta.dirname and this works locally (because the module is on FS), and then they publish their module to a HTTP server and then it is imported as a https: module, then the code stops working. This breaks portability.

Any code that uses fileURLToPath isn’t portable. If we don’t provide these helpers, it’ll just mean that people continue to use fileURLToPath and therefore they make code that’s not portable that way versus the import.meta.dirname way. I don’t think we should deny people convenience helpers just because they can’t be used everywhere; any code that intends to work with paths (whether via import.meta.dirname or via fileURLToPath) by definition isn’t intended to run from an HTTPS URL or in a browser environment.

Node also runs code from HTTPS URLs, and from data: URLs. So we have the same concern.

[GeoffreyBooth]

I think since Bun has already shipped this and Node intends to (either under import.meta.node or ideally at the top level, if we can find consensus) maybe the best way forward is to create an optional spec. Something like “for runtimes that want to ship import.meta properties to define the current module’s path and path-minus-filename (__filename and __dirname), the properties should be called ___ and ___ and have these specifications.” And it would define the details such as trailing slashes and how to handle non-filesystem modules. Then Bun and Node can each ship the feature according to the spec, and Deno can opt out; but if the Deno team changes their minds, they would add the feature according to the WinterCG spec. And I at least would welcome Deno’s involvement in drafting the spec, whether or not they plan to implement it.

[ljharb]

Filesystem modules and url-fetched modules are fundamentally different; I’m not sure why that portability is expected.

[pi0]

@ljharb I agree that modules that would (optionally) depend on the filesystem (filename, dirname) are probably not designed to work from a CDN.

But I guess the standpoint of Deno is that with a stricter standard (imort.meta.{url,resolve}) modules can be always imported from a URL and also be able to operate on the local filesystem. Kinda enforcing developers to make CDN-friendly modules with cost of little bit harder DX. (ie: The new props can lead to encouraging developers to make libraries that are not CDN friendly)

I guess my question is that, at this point is "filesystem support" part of common-minimum-api spec? (because if not, i think as was talking in yesterday meeting we might simply delegate it to (scoped) runtime specific implementation rather than standard). There is so more to it. URL is (almost!) a web standard. Filesystem especially considering lovely windows, is not.