ES modules: syntax import vs preprocessing cs plugins

[Claus Reinke]

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.

- ES modules:
    compile-time imports allow for syntax import, once
    syntax declarations/exports/macros are introduced

- node modules:
    require.extensions [2] (long time undocumented) allows
    registering alternative loaders for preprocessing alternative
    syntax (coffeescript, streamline, ..)

- require.js/AMD: loader plugins allow to handle alternative
    resource formats as module dependencies [3,4]

I just wanted to make sure that participants in this discussion
are aware of these similarities. [4] does briefly compare AMD's
loader plugins with node's require.extensions.

Btw: for all the usefulness of plugins, they do seem to express
syntax dependencies (which plugin to use) differently than code
dependencies (which modules to load).

Claus
http://clausreinke.github.com/

[1] http://calculist.org/blog/2012/06/29/static-module-resolution/
[2]
http://nodejs.org/docs/latest/api/globals.html#globals_require_extensions
[3] http://www.sitepen.com/blog/2012/06/25/amd-the-definitive-source/
[4]
http://tagneto.blogspot.ca/2012/06/es-modules-suggestions-for-improvement.html