Will it be possible to retrieve a loaded module's exports synchronously?

Caridy Patiño caridy at gmail.com
Wed Feb 24 23:53:48 UTC 2016


There is no such thing as a `key` in 262 (module spec). The `key` is a concept defined by the loader, and there it is not opaque.

> For my purpose the I would be interested in resolving the "name" so the module exports can be retrieved.

Can you explain more? Resolving from where? The context matters for the resolution process, e.g.: the referral can define how to resolve a module identifier. As for retrieving the module exports, you have to go thru the APIs that will guarantee that those exports are ready to be consumed, and those are the `import` statements, the `import()` calls, and `Reflect.Module.evaluate()`, you have no other way to access those exports in a way that is reliable. Via the registry, you can attempt to inspect every module status in the registry, trying to access the namespace exotic object via ModuleStatus.prototype.module getter, but there is no guarantee that you get it, it depends on the current stage of the module in the pipeline.

/caridy

> On Feb 24, 2016, at 6:40 PM, John Lenz <concavelenz at gmail.com> wrote:
> 
> 
> On Wed, Feb 24, 2016 at 3:28 PM, Bradley Meck <bradley.meck at gmail.com <mailto:bradley.meck at gmail.com>> wrote:
> In Node we can get the import path synchronously just from the parsed module, as proposed API in https://github.com/bmeck/node-eps/blob/es6-module/002-es6-modules.md <https://github.com/bmeck/node-eps/blob/es6-module/002-es6-modules.md> suggests. Can you clarify what you mean with
> 
> > The "key" appears to only be resolvable asynchronously
> 
> Which key? the path resolved from the source text?
> 
> From the spec the "key" appears to be opaque.  For my purpose the I would be interested in resolving the "name" so the module exports can be retrieved.
> 
> 
>  
> 
> On Wed, Feb 24, 2016 at 5:08 PM, Caridy Patiño <caridy at gmail.com <mailto:caridy at gmail.com>> wrote:
> I’m not sure what are you trying to do, but from within the module itself, you will have access to some metadata about the module, we have been chatting about `import()` and `import.<key>` as the imperative forms to import relative modules, accessing module’s metadata, and potentially a reference to the loader instance bound to the module (thru module status), but all that in up in the air.
> 
> From outside, things are more complicated, you have access to the registry of every loader instance, you can walk each registry, and do what you please, but there is no guarantee that the module status that you’re looking for is accessible (they can be removed from the registry and still function).
> 
> You should probably post this question on whatwg/loader repo.
> 
> /caridy
> 
> > On Feb 24, 2016, at 5:58 PM, John Lenz <concavelenz at gmail.com <mailto:concavelenz at gmail.com>> wrote:
> >
> > Background:
> >
> > I'm trying to plan a migration to ES6 modules.  For interop with the existing systems in the short-medium term, I would like to be able to retrieve a loaded modules exports synchronously (basically a "get or fail").
> >
> > It looks like retrieving the exports synchronously is possible using the Registry object, however the registry requires that you have an appropriate "key".  The "key" appears to only be resolvable asynchronously which means the whole operation must async.
> >
> > Am I missing something?
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160224/11525e44/attachment-0001.html>


More information about the es-discuss mailing list