ES modules: syntax import vs preprocessing cs plugins

Claus Reinke claus.reinke at talk21.com
Tue Jul 3 13:22:15 PDT 2012


>> When reading Dave's post on "Static module resolution" [1],
>> the section on "Future-compatibility for macros" struck me
>> as a case where users/proponents of different module systems
>> seem to be talking past each other. All agree that there is an
>> important feature, but the approaches differ so much that the
>> common purpose may not be obvious.
>
> IMO this feature should be staged for addition after we get modules in ES.

Can we agree what the feature is, though? Macros are not
scheduled for this round, loader plugins are in current use
with requirejs/AMD, as is require.extensions in node.

Looking closer at

http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders

there are interesting options for the Loader constructor, namely
the resolve, fetch and translate hooks. Those look as if the existing
features of current module systems could be emulated. An extended
loader could be chained with the system loader.

However, I see two problems:

- is there a way to use extended loaders with the module
    syntax for import/export? Some way to extend the system
    loader, before syntactic module loading commences?

- since Loader.prototype.load is asynchronous, how does
    one export from a dynamically loaded module, and how
    does one integrate a dynamically loaded module in the
    normal module dependency resolution?

Claus
 



More information about the es-discuss mailing list