moduleName, __modulename or __dirname

[johnjbarton]

We use node __dirname in Traceur and I'd like to substitute something that would work under EcmaScript modules.

In node, module source code is wrapped in a function:

'(function (exports, require, module, __filename, __dirname) { ',
    '\n});'

that, in effect, extends the language with module-specific operations and values. The ES module solution provides alternatives for the first three arguments. The last two are redundant and in other discussions we've used __moduleName as a substitute, where the value is set to the normalized name (and we assume the normalized name is a value path on the system we are running).

What shall we be doing for this case? Do we need to justify adding this feature?

[caridy]

Do we need to justify adding this feature?

yes, absolutely. in theory, neither __filename and __dirname will be used in CJS to require a module, why should we care?

If we can justify the need for it, we can probably provide extra metadata when using import {<something>} from this module;, which should be extensible :)

[johnjbarton]

Here are some use cases for a string known within a module that can be used to fetch the module:

1. Constructing a sites map entry dynamically,
2. Constructing a package version number from a version number embedding in a path,
3. Dynamically loading test cases relative to a test directory.
4. Publishing a service name equal to a module name in a relocatable way (./localChoice/Foo/FooService known to the "Foo" library code as ./FooService).

These cases are from uses in Traceur. More generally, any code that might in future need __filename or __dirname cannot be written in standard ES6 because these values are not available.

[caridy]

:+1: I like 1 and 2. Let's keep this around until we discuss the metadata exposed thru import ... from this module;.

[bmeck]

Is there any reason we cannot use a prefixing solution rather than IIFE for this? For node this would be something like replacing Module.wrap to generate this instead:

`let __filename=${...};let __dirname=${...};${src}`

Minor effect that is going to be visible is you can no longer access arguments or do a preemptive return

[caridy]

we have discussed how to access metadata from inside the module, that was two meetings ago (sept meeting notes - last day), and we will be providing a mechanism to access them. Not need to use IIFE for this.

[bmeck]

@caridy are those public somewhere? I don't see it referenced in the repo

[caridy]

https://github.com/rwaldron/tc39-notes/blob/master/es7/2015-09/sept-24.md

close to the end, look for import.context.

I will keep this issue open until we specced this.