NodeJS's __filename/__dirname in ES6 Modules

Andrea Giammarchi andrea.giammarchi at gmail.com
Sat Jan 21 18:22:48 UTC 2017


Absolutely, and same could be done through the browser if these info are
available and the server grants reading/listing options, which is why I am
exposing exactly the same way NodeJS is doing, through `__filename` and
`__dirname`, both constants and different per each imported module.

On NodeJS world, and overall in CommonJS environments, these are also
de-facto standard and already there. While a bit ugly, name convention
speaking, I wouldn't mind having the same via `import()`. It would be
nothing new to learn.

Regards

On Sat, Jan 21, 2017 at 6:10 PM, Gil Tayar <gil at tayar.org> wrote:

> Andrea,
>
> While it is true that "filename/URL" and "dirname" are not really
> important in the browser world, they are used a lot in the Node world to
> read various resources that reside in the same directory (or near the same
> directory) as the module.
>
> On Sat, Jan 21, 2017 at 7:49 PM Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> FWIW I have both `__filename` and `__dirname` implemented in common-js
>> package runtime, and these are resolved as absolute path from the root,
>> unless imported externally where these are resolved as absolute URLs.
>>
>> Although I must say beside providing some debuggable information, without
>> a core path module I don't see much added value in having these two
>> references.
>>
>> I still load relatively via `module.import('./lib')` or
>> `module.import('../js/file')`
>>
>> Regards
>>
>>
>>
>> On Sat, Jan 21, 2017 at 5:02 PM, Bradley Meck <bradley.meck at gmail.com>
>> wrote:
>>
>> Please see https://github.com/tc39/proposal-dynamic-import#an-
>> actual-function
>>
>> As per `"currentDir()" and "currentFile()"` this may not make sense for
>> all URLs. Please use https://url.spec.whatwg.org/ which ships in Node
>> v7+ under `require('url').URL` and the proposal to bring it into the
>> language itself https://github.com/jasnell/proposal-url . 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 tayar.org> 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 gmail.com>
>> wrote:
>>
>> The current trend is towards the https://github.com/nodejs/
>> node-eps/pull/39 rewrite which does not have magic variables
>> https://github.com/bmeck/node-eps/blob/b14276ca093fac9cbc3b72ff5433df
>> 35ae67fb59/002-es-modules.md#341-environment-variables
>>
>> There are ideas about exposing the URL of the current ESM via something
>> like https://docs.google.com/presentation/d/1aq_
>> QjBUQTovj9aQZQrVzS7l1aiOs3ZNlk7wgNTUEMy0/edit#slide=id.g16ab11d101_0_22
>>
>> On Fri, Jan 20, 2017 at 10:42 AM, Gil Tayar <gil at tayar.org> wrote:
>>
>> While reading Dominic Denicola's spec for dynamic import() at
>> https://github.com/tc39/proposal-dynamic-import, 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 mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170121/7b5183c6/attachment.html>


More information about the es-discuss mailing list