Module import/export bindings

Kyle Simpson getify at gmail.com
Sun Mar 15 15:42:12 UTC 2015


> Regarding the internal server error

Ahh, thanks. Yeah, not only is it confusing to see the "edit" button, but especially since clicking it asks you to login to the site as if to verify your authorization to do such. :)


> I guess you'd intended to write export {foo as default} instead of export default foo...

Well, no, until your reply I didn't realize there was a difference in the two! Yikes. That's… surprising.

Just to make sure I'm crystal clear… in my original example:

```js
var foo = 42;
export default foo;
foo = 10;
```

That exports a binding only to `42`, not `10`. But:

```js
var foo = 42;
export {foo as default};
foo = 10;
```

That exports a binding to `foo` so the importer sees `10`. Correct?


> All three assignments throw a TypeError exception

Thanks for the clarifications!

Would it then be appropriate to explain that conceptually the binding would otherwise indeed be 2-way, but that the immutable/read-only nature of the bindings is what prevents an outside mutation of a module's internals? That is, without such bindings (and errors), a module could be changed from the outside?

Also, are these errors runtime or static? I'm guessing from the spec text you quoted they're runtime. If so, was there a reason they couldn't be static?

-----

I have some modules where the intentional design of the API has been for a consumer to be able to change property value(s) on the public API, and the module would behave differently corresponding to those values, almost like if they were "configuration".

I take it there's no way to do this directly on the module namespace (even with the namespace import) with ES6 modules? So basically to do that I'd have to export an object (called like `config`) that holds such intentionally mutable properties?

Similarly, the (much maligned but still somewhat popular) pattern of having module "plugins" which attach themselves on top of an existing API… sounds like this pattern is also not supported?


More information about the es-discuss mailing list