import { foo, bar } as obj from 'module

Caridy Patiño caridy at
Wed Dec 13 20:23:58 UTC 2017

those {} that you see in the export and import statements are not objects, it is just syntax. Yes, I know, people confuse them with objects, until they realize they aren’t. We probably should have chosen a different syntax to signal that it is a binding from the module’s environment record.

Another way to look at this is from the lenses of function declarations or function expressions, those {} that represent the body of the function are more closely related to what you use in the import/export statements that what you use for objects.

For those assuming that this will just fly through the staging process, it will not! There are many issues when considering it a object declaration.


> On Dec 13, 2017, at 2:07 PM, dante federici <c.dante.federici at> wrote:
> Definitely make a proposal for this -- I'm pretty tired of colliding utility function names and having to aggressively namespace them.
> It's been said but I want to just throw in another voice that this will 100% work with tree shaking, and as we get better at organizing our modules and dependencies, it'll become more apparent.
> With all the pushes toward pure functional code, utility modules and libraries will benefit more and more from tree shaking and clear / strong import/export syntax.
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list