NodeJS's __filename/__dirname in ES6 Modules

Gil Tayar gil at
Sat Jan 21 18:08:31 UTC 2017


My point was not file path vs URL (if that was what you were referring to),
but rather the fact that the special "import", which needs the current
location to operate, is not special, but that it may be a *family* of
functions that need this information, and I gave as an example
__dirname/__filename in Node.

What I propose is to find a common way for the developer to import those
module-specific functions like import/dirname/filename/fileurl.

As why they can't be regular functions (per - it is*
true* that they need to be something "special". But they can,
alternatively, *be imported *from someplace special, e.g. my idea of import
{import} from 'js:system'.

While I suspect that for a phase 3 suggestion it is a bit too late to
change it wholesale (and the current import spec is phase 3, AFAIK), I just
thought to drop it here to see if it sticks.

But thanks for the info on __dirname/__filename in ESMs.

On Sat, Jan 21, 2017 at 7:03 PM Bradley Meck <bradley.meck at> wrote:

> Please see
> As per `"currentDir()" and "currentFile()"` this may not make sense for
> all URLs. Please use which ships in Node v7+
> under `require('url').URL` and the proposal to bring it into the language
> itself . Getting the "directory"
> of a URL would be ~= `new URL('.', file_url)`.
> On Sat, Jan 21, 2017 at 10:42 AM, Gil Tayar <gil at> wrote:
> Thanks!
> Makes total sense. So why not have Domenic's "import" be a real function
> that comes from this "js:context", thus obviating the need for a new
> JavaScript operator?
> While I realize that "js:context" will a Node thing, we could have a
> special import (e.g. import {...} from "js:system") that enables the system
> to expose real functions, of which one is "dynamicImport" and others would
> be "currentDir()" and "currentFile()".
> In other words - Domenic exposed a real need, but it seems that this need
> is more general, and not specific only to dynamic import, and should be
> added to the spec as a special import, just like it may be in Node.
> On Fri, Jan 20, 2017 at 6:48 PM Bradley Meck <bradley.meck at>
> wrote:
> The current trend is towards the
> rewrite which does not have
> magic variables
> There are ideas about exposing the URL of the current ESM via something
> like
> On Fri, Jan 20, 2017 at 10:42 AM, Gil Tayar <gil at> wrote:
> While reading Dominic Denicola's spec for dynamic import() at
>, I read his rational for
> not having import be a regular function, but rather a "syntactic form". The
> idea is that import() needs to be "in the scope" of the current module, as
> it needs to resolve the module path it is given relative to the current
> module's.
> Thinking about it some more, I thought it would be a pity for import to be
> so "special", and asked myself whether there will be more features that
> will need to be "module-aware" like import().
> And there are! (I think...) - __filename and __dirname in NodeJS are
> exactly such features. Actually, anything passed to the function wrapping
> each NodeJS module is such a feature, but going over them, only __filename
> and __dirname are not immediately related to the module mechanism.
> So my question is this (and it is specifically addressed to the NodeJS
> implementors in the group): in NodeJS's implementation of ES6 modules, how
> will __dirname and __filename be implemented? Will there still be a
> function wrapper like in the current module implementation? Or will
> __dirname and __filename be a "syntactic form" like import()? Or something
> else?
> Thanks,
> Gil Tayar
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list