Will it be possible to retrieve a loaded module's exports synchronously?
concavelenz at gmail.com
Thu Feb 25 00:57:49 UTC 2016
var exports = System.loader.registery.get('path/file.js');
On Wed, Feb 24, 2016 at 3:53 PM, Caridy Patiño <caridy at gmail.com> wrote:
> 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.
I don't see where the value of the key/meaning of the key is defined. Can
you be more specific as to what it is required to be?
> 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?
A script or a module. If this isn't helpful, I'm unclear on what the
possible values for "where" are.
> The context matters for the resolution process, e.g.: the referral can
> define how to resolve a module identifier.
The context is user code, where the available "name" of a module would be
identical to what would be used in an import declaration.
> 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.
"import", "import()" and "evaluate" all force a load and a wait. Forcing a
load is distinctly not what is desired here. I understand that a load
could be "under way" but if one wanted to wait they would simply call
> 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.
I having a hard time here to trying to understand what I can say
differently to explain what I desire: I need to know if a module is loaded
and ready, if it is I want the module exports immediately.
> 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>
>> In Node we can get the import path synchronously just from the parsed
>> module, as proposed API in
>> 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
>> On Wed, Feb 24, 2016 at 5:08 PM, Caridy Patiño <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
>>> You should probably post this question on whatwg/loader repo.
>>> > On Feb 24, 2016, at 5:58 PM, John Lenz <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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss