Is any default export binding included in the exported namespace object?

[benmosher]

Reference: http://www.ecma-international.org/ecma-262/6.0/#sec-getexportednames

export * from '...' does not re-export the default binding from the referenced module.

It's unclear to me whether this proposal would export only the bindings that GetExportedNames returns, which is to say, everything but the default export.

So: is any default export included in the exported namespace exotic object?

(thanks! 😄 also ref: import-js/eslint-plugin-import#328)

[caridy]

@guybedford has been pushing for considering default just another exported name, and therefore make it more simple to reexport defaults when using *, etc. We are not sure yet, and hopefully during the next meeting in Munich we will get a chance to discuss this with others, and make a final call about this.

[guybedford]

This is a natural asymmetry that will continue to be confusing especially when these proposals land. I still think excluding default from export * was a huge mistake.

[guybedford]

I really can't overstate how bad this is. It inhibits the creation of eg automatic index.js files that could contain export * from './actual-main.js'. See whatwg/html#613 for further discussion too.

[guybedford]

Just to clarify, this was something that was added into ES6 without a unified consensus behind the reasoning. In previous (unfortunately private) email discussions Allen has even mentioned that this would be something that could be changed, but that his concern to this use case is based on the principles discussed at https://www.mail-archive.com/[email protected]/msg03762.html, and he thinks it is a refactoring hazard, although I do not agree with this argument.

[caridy]

@guybedford if you make a formal proposal, I can help to push this forward!

[guybedford]

Thanks @caridy I will get to this.

[Jamesernator]

I definitely think default should just be another name given that it doesn't really have any special behavior (just special syntax export default .../import <default> from ... but it doesn't change semantics).

Also does anyone else find the export * from "module" to overall to just be bizarre with how it deals with ambiguous names and just straight up vanishes them when doing import * as ns from "./someAmbiguous export * s.js"?

I guess this proposal would do the same thing in that case e.g.

// example.js
export * as someMod from "./ambiguousMod.js"

// other.js
import { someMod } from "./example.js"
someMod.ambigiousName // undefined

Personally I'd much rather see ambiguous entries create a module namespace with a getter for the ambiguous names that simply throws an error on trying to use it, but I suspect that's probably not going to happen.

[jdalton]

Since this is creating a namespace object we'll follow this existing mechanism to do so.