restrictions on module import export names

Calvin Metcalf calvin.metcalf at
Thu Jan 30 05:38:14 PST 2014

sorry guys, was getting confused on VariableStatement vs
AssignmentExpression, gist is updated with correct examples, I guess it
seems somewhat overly complicated having 4 different ways to export things
each with their own arbitrary restrictions which leads to weirdness, e.g.
if you want to export an array as `foo` you could do

export let foo = [stuff];

but if foo was already defined you probably wouldn't want to do that, but
you wouldn't be able to do this (I believe).

export { [stuff] as foo}

as you can only use identifierNames or identifierReferences here even
though they are going to be discarded, so

let _foo = [stuff];
export { _foo as foo };

would be the only way

the other thing is on second thought more of an issue with imports not
being expressions,  yes this code might be an edge case

let app = module.exports = require('express')();

but it's from in the wild code, slightly less ridicules example would be


var projs = [


is there a reason import ModuleSpecifier can't be an expression which
evaluates to either an object with all the imports or the default export
when it's used as an AssignmentExpression (I think I'm using that one

On Wed, Jan 29, 2014 at 9:55 PM, Kevin Smith <zenparsing at> wrote:

>> ```js
>> let app = module.exports = require('express')();
>> ```
> Not impossible.  Possibly:
>     import express from "express";
>     let app = express();
>     export { app as default };
> I think you're attempting to optimize edge cases.
> Also, I agree with Domenic.  Read the grammar for the current spec and try
> not to post syntax errors that might lead others astray  : )

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

More information about the es-discuss mailing list