A few more questions about the current module proposal

Sam Tobin-Hochstadt samth at ccs.neu.edu
Thu Jul 5 11:11:23 PDT 2012


On Thu, Jul 5, 2012 at 8: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.

Exactly.  And note that the compiled CoffeeScript code will be able to
use `import`, which will again use the same loader, with the same
translate hook.  So however modules are added to CoffeeScript, those
modules will be able to depend on other module written in CS, JS, or
anything else.

> One question, though:  branching on the file extension, as above, will not
> generally work.  The source code might be served through a URL that does not
> have a file extension.  On the web though, we'll generally have access to a
> Content-Type header.  In the current design, there's doesn't appear to be a
> way to get that information.

This is an excellent suggestion.  In general, there won't be a
Content-Type header (or any other kind of metadata) in every JS
environment, so the right thing may be to add a `metadata` additional
parameter, and then have HTML specify that browser embeddings of JS
should provide particular forms of that metadata.  I'll talk with Dave
about this once he's back.

> One possibility for getting the Content-Type header would be to override the
> fetch hook and use cross-domain XHR, but that seems like a lot of duplicated
> code just to get data that's already being received by the browser.

Right -- we want to avoid programmers having to do the browsers' job.
-- 
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list