Modules, Concatenation, and Better Solutions

Patrick Mueller pmuellr at
Tue Oct 16 06:58:20 PDT 2012

On Tue, Oct 16, 2012 at 9:21 AM, Kevin Smith <khs4473 at> wrote:

> Patrick, it must be the other way.  Here's why:
>     module A {
>         export function f() { console.log("A"); }
>     }
>     A.f();
> No import required before usage of an inline module.  There is a
> concatenation strategy which will preserve order-of-execution, but but
> without some scope artifacts:

So, first, I've been barely following the ES Modules bits - I wanted to
chime in on how I "expected" it would work based on module stuff I've been
playing with.

The scoped module definition in your gist is horrifying.

I wouldn't expect to see this pattern from a concatenator though.  I'd
expect that they would do an "import" of A before referencing anything it.
 This would typically be the "main" referenced by a run of the
concatenator, which would spit out the import for the "main" module.  But
this couldn't change the dynamics here, right?  It's not like if you
changed your snippet above to first "import f from A" before invoking it,
that the module factory would NOT be run first, right?

Unfortunate.  Perhaps there's a story around wrapping each concatenated
module in another module, deferring the run of the actual factory until
first "really" used, via proxies, or something.  Ick.

I suppose I should dig in a bit more on this ES module stuff ...

I guess I'm mostly interested in seeing if there's a module story we can
transpile in, that would also allow concatenation in the typical sense used
today, so people could start playing with this stuff.  Eg, I could see
taking something Browserify as we know it today, allowing you to use ES
module syntax, and have it "just work".

Maybe that's too much to ask for, or that we'll have the real thing in
short order, or for some other reason that doesn't make sense.  One of
those reasons would be that those "ES modules that Browserify can
understand" wouldn't be understandable by node.js, directly, which could be
a practical issue.

Patrick Mueller
pmuellr at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list