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 < [email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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/b14276ca093fac9cbc3b72ff5433df35ae67fb59/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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
