ES modules: syntax import vs preprocessing cs plugins

Sam Tobin-Hochstadt samth at
Tue Jul 3 15:36:16 PDT 2012

On Tue, Jul 3, 2012 at 4:22 PM, Claus Reinke <claus.reinke at> wrote:
>>> 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
> 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:

[problems snipped]

There are two issues here.  One is what code evaluated in nested
loaders looks like.  That's entirely up to the loader, but it
certainly can use `import` and `export` and all of the other features
of the module system.  Those references are resolved by the loader
being used.

The second question is how we specify a particular loader to use.
This is easy to do in JS code: `myLoader.load(url, callback)`.  If we
want convenient syntax for using this in a particular environment,
then that would require an extension to the environment, such as an
HTML declaration to use a particular loader for the rest of the page,
or for a particular script tag.  This is certainly doable, but
requires coordination outside of TC39.
sam th
samth at

More information about the es-discuss mailing list