A few more questions about the current module proposal

James Burke jrburke at gmail.com
Thu Jul 5 22:35:28 PDT 2012


On Thu, Jul 5, 2012 at 5:56 AM, Kevin Smith <khs4473 at gmail.com> wrote:
>> Will heterogenous transpiling in a web app be supported? Can a JS
>> module depend on a CoffeeScript file, and vice versa?
>
>
> Right - Sam's example of having a specific CoffeeScript loader isn't going
> to actually work for this reason.  Instead, we'd have to figure out which
> "to-JS" compiler to use inside of the translate hook.
>
>     let maybeCoffeeLoader = new Loader(System, {
>
>       translate(src, relURL, baseURL, resolved) {
>
>         // If file extension is ".coffee", then use the coffee-to-js
> compiler
>         if (extension(relURL) === ".coffee")
>           src = coffeeToJS(src);
>
>         return src;
>       }
>
>     });
>
> You could use the resolve hook in concert with the translate hook to create
> AMD-style plugin directives.  It looks pretty flexible to me.

Right, I do not believe file extension-based loader branching is the
right way to go, see the multiple text template transpiler uses for
.html in AMD loader plugins. The module depending on the resource
needs to choose the type of transpiler.

So as you mention, a custom resolver may need to be used. This means
that there will be non-uniform dependency IDs floating around. That
seems to lead to this chain of events:

* packages that use these special IDs need to communicate that the end
developer needs to use a particular Module Loader implementation.
* the end developer will need to load a script file before doing any
harmony module loading when using those dependencies.
* People end up using loaders like requirejs.
* Which leads to the dark side. At least a side I do not want to see.

It is also unclear to me what happens if package A wants a particular
ModuleLoader 1 where package B wants ModuleLoader 2, and both loaders
like to resolve IDs differently.

This is why I favor "specify transpiler in the ID, transpiler is just
another module with a specific API". If the default module loader
understands something along the lines of "something!resource" means to
call the "something" module as a transpiler to resolve and load
"resource", the module IDs get uniform, and we can avoid a tower of
babel around module IDs, and the need for bootstrap script
translators.

James


More information about the es-discuss mailing list