Standard modules - concept or concrete?

Sam Tobin-Hochstadt samth at
Thu Jun 20 07:03:09 PDT 2013

On Thu, Jun 20, 2013 at 9:55 AM, Kevin Smith <zenparsing at> wrote:
> I would think the advantage of running compile-time checks against the
> global object is that it can catch errors that we currently use linters for:
>     // OOPS - forgot this line!
>     // import { x } from "foo";
>     function someRareCase() {
>         x(); // Reference error?
>     }
> That's useful, but it comes at the price of treating the global object as if
> it were a static thing, and not dynamic.  From my point of view, though, a
> dynamic global object is just how it goes with Javascript.  I think this
> kind of static checking should be left to linters, unless we are adopting a
> policy of actively discouraging dynamism for the global object.

We could:

1. Give up on static checking of unbound variables in modules.
2. Take the global object off the scope chain in modules.
3. Adopt a compromise.

We think static checking for unbound variables is valuable, and
letting people write `console.log` without having to import anything
is valuable. Thus, option 3.


More information about the es-discuss mailing list