Modules, Concatenation, and Better Solutions

Patrick Mueller pmuellr at yahoo.com
Wed Oct 17 16:50:42 PDT 2012


On Wed, Oct 17, 2012 at 5:04 PM, Russell Leggett
<russell.leggett at gmail.com>wrote:

>     module "a.js" {
>         import b from "b.js";
>         console.log("a");
>         export let a = "a";
>     }
>     module "b.js" {
>         console.log("b");
>         export let b = "b";
>     }
>
>     //main.js
>     import a from "a.js";
>     console.log("main");
>
> The idea here, is to allow a new bit of syntax where the module identifier
> is a string literal. If that is the case, it assumes the module is loaded
> in place of a file, where the url for the file is the value of the string
> literal. Just to be clear, though, it doesn't actually execute the module
> at all - it just caches it in the loader.
>

Ya, I kinda like that.  Basically let's me mark an "internal" module as an
"external one" - I even get to assign a "file name", which maybe a debugger
can make sense of.  Win!

OTOH, this is yet another feature; the feature set for modules seems pretty
rich already - compared to what you have with CommonJS.

If there's any interest in simplifying ... might be worth noting that, in
node, there is no notion of "internal modules".  No one seems to mind.
 Maybe just get rid of them?  Only top-level modules, and they're either
from a "file" or you've poofed one up using new Module(nameString,
codeString).  Concatenators would of course use the Module constructor.
 Just like we use eval() today (with //@sourceURL!) in concat'd files to
provide per-embedded-file debugging.

-- 
Patrick Mueller
pmuellr at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121017/6a6c1886/attachment-0001.html>


More information about the es-discuss mailing list