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 <[email protected]> wrote: > > > On Wed, Feb 24, 2016 at 3:28 PM, Bradley Meck <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
