loader
loader copied to clipboard
moduleName, __modulename or __dirname
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?
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 :)
Here are some use cases for a string known within a module that can be used to fetch the module:
- Constructing a
sites
map entry dynamically, - Constructing a package version number from a version number embedding in a path,
- Dynamically loading test cases relative to a test directory.
- 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.
:+1: I like 1 and 2. Let's keep this around until we discuss the metadata exposed thru import ... from this module;
.
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
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.
@caridy are those public somewhere? I don't see it referenced in the repo
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.