A few more questions about the current module proposal

James Burke jrburke at gmail.com
Wed Jul 4 14:45:03 PDT 2012


On Wed, Jul 4, 2012 at 11:13 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> We've thought a lot about compile-to-JS languages, and a bunch of the
> features of the module loader system are there specifically to support
> these languages.  You can build a loader that uses the `translate`
> hook to perform arbitrary translation, such as running the
> CoffeeScript compiler, before actually executing the code.  So you'll
> be able to write something like this:
>
> let CL = new CoffeeScriptLoader();
> CL.load("code/something.coffee", function(m) { ... });

Will heterogenous transpiling in a web app be supported? Can a JS
module depend on a CoffeeScript file, and vice versa? What about a JS
module depending on a CoffeeScript and text resource? What would that
look like?

For instance, it is common in requirejs projects to use coffeescript
and text resources via the loader plugin system. While the text plugin
is fairly simple, it can be thought of as a transpiler, converting
text files to module values that are JS strings. It could also be
"text template" transpiler that converts the text to a JS function,
which when given data produces a custom HTML string.

For requirejs/AMD systems, the transpiler handler is part of the
module ID. This means that nested dependencies can use a transpiler
without the top level application developer needing to map out what
loader transpilers are in play and somehow configure transpiler
capabilities at the top level before starting main module loading.

It also makes it clear which transpiler should be used for a given
module dependency. Each module gets to choose the type of transpiler:
for a given .html file, one module may want to use a text template
transpiler where another module may just want a raw text-to-string
transpiler. Both of those modules can be used in the same project as
nested dependencies without the end developer needing to wire them up
at the top level.

James


More information about the es-discuss mailing list