<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>I still load relatively via `module.import('./lib')` or `module.import('../js/file')`</div><div><br></div><div>Regards<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 21, 2017 at 5:02 PM, Bradley Meck <span dir="ltr"><<a href="mailto:bradley.meck@gmail.com" target="_blank">bradley.meck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Please see <a href="https://github.com/tc39/proposal-dynamic-import#an-actual-function" target="_blank">https://github.com/tc39/<wbr>proposal-dynamic-import#an-<wbr>actual-function</a><div><br></div><div>As per `"<span style="font-size:12.8px">currentDir()" and "currentFile()"` this may not make sense for all URLs. Please use <a href="https://url.spec.whatwg.org/" target="_blank">https://url.spec.whatwg.<wbr>org/</a> which ships in Node v7+ under `require('url').URL` and the proposal to bring it into the language itself <a href="https://github.com/jasnell/proposal-url" target="_blank">https://github.com/<wbr>jasnell/proposal-url</a> . </span><span style="font-size:12.8px">Getting the "directory" of a URL would be ~= `new URL('.', file_url)`.</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 21, 2017 at 10:42 AM, Gil Tayar <span dir="ltr"><<a href="mailto:gil@tayar.org" target="_blank">gil@tayar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks!</div><div><br></div>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?<div><br></div><div>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()".</div><div><br></div><div>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.</div><div><br></div></div><div class="m_-5600516302675924390HOEnZb"><div class="m_-5600516302675924390h5"><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 20, 2017 at 6:48 PM Bradley Meck <<a href="mailto:bradley.meck@gmail.com" target="_blank">bradley.meck@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_-5600516302675924390m_-8963717410401605761gmail_msg">The current trend is towards the <a href="https://github.com/nodejs/node-eps/pull/39" class="m_-5600516302675924390m_-8963717410401605761gmail_msg" target="_blank">https://github.com/nodejs/<wbr>node-eps/pull/39</a> rewrite which does not have magic variables <a href="https://github.com/bmeck/node-eps/blob/b14276ca093fac9cbc3b72ff5433df35ae67fb59/002-es-modules.md#341-environment-variables" class="m_-5600516302675924390m_-8963717410401605761gmail_msg" target="_blank">https://github.com/b<wbr>meck/node-eps/blob/b14276ca093<wbr>fac9cbc3b72ff5433df35ae67fb59/<wbr>002-es-modules.md#341-<wbr>environment-variables</a><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg"><br class="m_-5600516302675924390m_-8963717410401605761gmail_msg"></div><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg">There are ideas about exposing the URL of the current ESM via something like <a href="https://docs.google.com/presentation/d/1aq_QjBUQTovj9aQZQrVzS7l1aiOs3ZNlk7wgNTUEMy0/edit#slide=id.g16ab11d101_0_22" class="m_-5600516302675924390m_-8963717410401605761gmail_msg" target="_blank">https://docs.google.com/p<wbr>resentation/d/1aq_QjBUQTovj9aQ<wbr>ZQrVzS7l1aiOs3ZNlk7wgNTUEMy0/<wbr>edit#slide=id.g16ab11d101_0_22</a></div></div><div class="gmail_extra m_-5600516302675924390m_-8963717410401605761gmail_msg"><br class="m_-5600516302675924390m_-8963717410401605761gmail_msg"><div class="gmail_quote m_-5600516302675924390m_-8963717410401605761gmail_msg"></div></div><div class="gmail_extra m_-5600516302675924390m_-8963717410401605761gmail_msg"><div class="gmail_quote m_-5600516302675924390m_-8963717410401605761gmail_msg">On Fri, Jan 20, 2017 at 10:42 AM, Gil Tayar <span dir="ltr" class="m_-5600516302675924390m_-8963717410401605761gmail_msg"><<a href="mailto:gil@tayar.org" class="m_-5600516302675924390m_-8963717410401605761gmail_msg" target="_blank">gil@tayar.org</a>></span> wrote:<br class="m_-5600516302675924390m_-8963717410401605761gmail_msg"></div></div><div class="gmail_extra m_-5600516302675924390m_-8963717410401605761gmail_msg"><div class="gmail_quote m_-5600516302675924390m_-8963717410401605761gmail_msg"><blockquote class="gmail_quote m_-5600516302675924390m_-8963717410401605761gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_-5600516302675924390m_-8963717410401605761gmail_msg"><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg">While reading Dominic Denicola's spec for dynamic import() at <a href="https://github.com/tc39/proposal-dynamic-import" class="m_-5600516302675924390m_-8963717410401605761gmail_msg" target="_blank">https://github.com/tc39/propos<wbr>al-dynamic-import</a>, 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.</div><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg">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().</div><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg"><br class="m_-5600516302675924390m_-8963717410401605761gmail_msg"></div><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg">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.</div><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg"><br class="m_-5600516302675924390m_-8963717410401605761gmail_msg"></div><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg">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?</div><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg"><br class="m_-5600516302675924390m_-8963717410401605761gmail_msg"></div><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg">Thanks,</div><div class="m_-5600516302675924390m_-8963717410401605761gmail_msg">Gil Tayar</div></div>
<br class="m_-5600516302675924390m_-8963717410401605761gmail_msg"></blockquote></div></div><div class="gmail_extra m_-5600516302675924390m_-8963717410401605761gmail_msg"><div class="gmail_quote m_-5600516302675924390m_-8963717410401605761gmail_msg"><blockquote class="gmail_quote m_-5600516302675924390m_-8963717410401605761gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">______________________________<wbr>_________________<br class="m_-5600516302675924390m_-8963717410401605761gmail_msg">
es-discuss mailing list<br class="m_-5600516302675924390m_-8963717410401605761gmail_msg">
<a href="mailto:es-discuss@mozilla.org" class="m_-5600516302675924390m_-8963717410401605761gmail_msg" target="_blank">es-discuss@mozilla.org</a><br class="m_-5600516302675924390m_-8963717410401605761gmail_msg">
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" class="m_-5600516302675924390m_-8963717410401605761gmail_msg" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br class="m_-5600516302675924390m_-8963717410401605761gmail_msg">
<br class="m_-5600516302675924390m_-8963717410401605761gmail_msg"></blockquote></div><br class="m_-5600516302675924390m_-8963717410401605761gmail_msg"></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>