ES Modules: suggestions for improvement

David Herman dherman at
Wed Jun 27 10:43:40 PDT 2012

On Jun 27, 2012, at 10:32 AM, Isaac Schlueter wrote:

> On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich <brendan at> wrote:
>> var foo = 42;
>> ... foop ...
>> throws at runtime in ES1-5 if evaluation reaches the foop use, and (if you
>> wrap a module around that hunk of code, and there's no global foop property)
>> at compile-time (EarlyError) in ES6.
> I don't think that's a real problem.  Can you point to in-the-wild
> bugs caused by this?  Maybe it's a failure of imagination on my part.

Well, this was a relatively high-profile example:

> Consider:
> // far far away in another file entirely...
> import * from "foo";
> import * from "baz";
> console.log(x) // what?  where did THAT come from?

The client chose to use *. You don't have to use * if you don't want to. It's a convenience.

> x++; // do other importers of foo see x change? if so, spooky! if not,
> why not? is it foo's x or not?

Clients are disallowed from mutating another module's exports. (That's one of the things we're able to accomplish by making modules declarative rather than totally dynamic.)

> Dumping a bunch of symbols into my local scope is intrusive.

The module did not dump anything. The client chose to bulk-import them. The client is perfectly free not to.

> Yes that is a fair statement.  I don't see how we can add typo
> checking without also adding "you get to tell me what to call my local
> vars".  In every other place in the language, I get to decide what my
> vars are called, and typo-checking happens locally, not at a distance.
> That's not a gap, that's a feature.

Here I have no idea what you're talking about. Nothing about ES6 modules prevents you from locally controlling names. Local control over scope has always been one of the foremost principles of the entire design.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list