How can GetModuleNamespace throw a SyntaxError?
It has to do with circular exported bindings. And IMHO a SyntaxError is the wrong error to throw (it should really throw a ReferenceError, as it's a circular reference).
// foo.js
export {name} from "./bar.js"
// bar.js
export {name} from "./foo.js"
// main.js
import * as foo from "./foo.js" // Error!
See the note in 15.2.1.16.3: www.ecma-international.org/ecma-262/6.0/#sec-resolveexport. That should help you.
Thanks for the example. It doesn't seem to trigger that error path though.
When I ran it it threw a SyntaxError during ModuleDeclarationInstantiation step 9 when resolving indirect exports for one of the imported modules. It looks like that will always happen before we call GetModuleNamespace in step 12 of the invocation of ModuleDeclarationInstantation for the main module.
Jon
Isiah: your example triggers a different error. ResolveExport is taking care of detecting that particular case (whatwg.github.io/loader/#resolve-export, whatwg.github.io/loader/#resolve-export), it is also a SyntaxError :)
Jon: yes, it might be a redundant error, I will investigate more.
@Caridy: Then what does ResolveExport do in the ES6 spec? Or is it basically dead code?
Jon: yes, it might be a redundant error, I will investigate more.
/caridy
Module Records other than Source Text Module Records could return null
when calling
ResolveExport() in GetModuleNamespace(). The specification of the abstract ResolveExport() method
does not forbid this case.
On Dec 10, 2015, at 9:27 AM, Caridy Patiño <caridy at gmail.com> wrote:
Isiah: your example triggers a different error. ResolveExport is taking care of detecting that particular case (whatwg.github.io/loader/#resolve-export, whatwg.github.io/loader/#resolve-export), it is also a SyntaxError :)
Jon: yes, it might be a redundant error, I will investigate more.
The definition of ModuleDeclarationInstantiation given in 15.2.1.16.4 is only applicable to Source Text Modules, but an actual module circularity might involve implementation defined modules types that possibly might not perform the equivalent check. GetModuleNamespace is an abstract operation that can be applied to any kind of module so it must be prepared to deal with the case where a module reports that it can not provide an unambiguous binding for a requested name.
Thank you, that explains it.
Jon
In the definition of GetModuleNamespace (section 15.2.1.18), a SyntaxError is thrown if we fail to resolve an exported name:
What situation leads to this error?
I wasn't able to come up with an example that would make this happen, and my attempts all generated a SyntaxError at an earlier point. It seems that GetExportedNames should only return names that will successfully resolve, but I may be missing something.
Thanks,
Jon