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 <g...@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.m...@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 <g...@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@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >>
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
