ES modules: syntax import vs preprocessing cs plugins
claus.reinke at talk21.com
Tue Jul 3 13:22:15 PDT 2012
>> When reading Dave's post on "Static module resolution" ,
>> 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
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?
More information about the es-discuss