ES modules: syntax import vs preprocessing cs plugins

Claus Reinke claus.reinke at talk21.com
Wed Jul 4 01:50:03 PDT 2012


> 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.

I think there has been a disconnect in how you and I think about
using the new module loaders. Since you're involved in the design,
its probably my view that needs adjustment, but I'd appreciate if
your view could be made clearer on the module loader page. At
the moment, I do not have sufficient information to decide whether
the proposed functionality will be sufficient in practice.

To outline the disconnect, consider this simple static module
chain for a dummy project ab I might like to use:

    // a.js
    export var a = "a";

    // b.js
    import {a} from 'a';
    export var b = a+"b";

To use this in my main code, I again use static import

    // main.js (or perhaps a script element in index.html)
    import {b} from 'b';    // early failure-protection here
    .. other imports ..        // executed in sequence, but
                                         // can be loaded in parallel
    .. lots of code that uses imports ..
                                        // if this code is part of a HTML
                                        // source, we can use imports
                                        // to fill static HTML syntax here

Now, if I need to use module loader hooks while importing
the ab project, I thought there would be a way to extend
the default loader, then keep the rest of main.js unchanged.

Instead, you seem to say that any use of module loader
functionality for ab will require a rewrite of main.js. The module
loader API gives us two options for this rewrite. The obvious
option is to move main.js code into the callback

    // main.js
    let myLoader = new Loader(...);
    myLoader.load('b',function(bMO){
        let {b} = bMO;    // no more early failure here

        .. other imports ..   // these have to be rewritten,
                                        // cannot use module syntax,
                                        // are now loaded in sequence
                                        // (instead of in paralell)

        .. lots of code that uses imports ..
                                        // import API failures can happen
                                        // at any time now;
                                        // no static context functionality 
can be
                                        // used here (eg, if main was 
originally
                                        // part of an HTML file, and the 
imports
                                        // were used in <body>)
    });
    // there is no easy way to use the imports at this point

If the callback represents the dynamic continuation of .load,
there is also the option of extending the import chain instead,
which gives us a static continuation (one in which we can
use the static module syntax in code that can use the imports)

    // main.js
    let myLoader = new Loader(...);
    myLoader.load('old-main',function(mainMO){
        let {...} = mainMO;
        // can connect mainMO exports to original context here
    });
    // cannot easily use mainMO or other imports here

    // old-main.js
    import {b} from 'b';    // early failure-protection here
    .. other imports ..        // executed in sequence, but
                                         // can be loaded in parallel
    .. lots of code that uses imports ..
                                         // cannot use context functionality 
here
    export ...                       // can return something to
                                         // importer

These are the two options that come to mind. Have I missed
anything? Is it the second option that you are thinking of when
you say "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."?

Claus
 



More information about the es-discuss mailing list