Dynamic modules - throw on star exports

[guybedford]

No description provided.

[guybedford]

(the last commit is the new change)

[littledan]

Doesn't the need for all this | null/extensibility stuff go away?

[littledan]

Ah, never mind, no, this is how CJS modules are directly (it is just never that a ESM is like that), right?

[guybedford]

Yes, the pending state still stands - this is for the case on the 7th slide of https://docs.google.com/presentation/d/1--k5tJmhXJeLlUOmBdHGK3my9VCbZVL0MF8OrTeqS0I/edit?usp=sharing.

[guybedford]

I've added another commit to try and clarify the note cases here even further. Would value feedback on the wording here before updating the ECMA262 PR.

[guybedford]

I've added an additional commit to this at 1b409d3, which is basically just reducing a minor spec complexity.

To explain:

• If the module hasn't executed yet, GetModuleNamespace calls GetExportedNames which must return null to go into the pending state, which then passes handling of the namespace finalization over to the dynamic modules spec.
• If the module has already executed though, GetModuleNamespace should do the finalization rather than the dynamic modules spec, so GetExportedNames in this case only should actually return the valid export names.
• This means that the definition of a "deferred exports" module isn't just that it returns null from GetExportedNames anymore, but that it returns null in the right cases (during star reexport lookups or for the module's own namespace when the module is unexecuted and detecting this difference based on the ns argument we added to GetExportedNames).

One way to make this a bit simpler would just be to always have the dynamic modules spec create the namespaces, and then to always create namespaces for all modules upfront instead of lazily. This is just in spec text though, so implementations could still make namespaces lazily in their own work if they want to.

The spec text then simplifies as provided in 1b409d3 (no new argument needed for GetExportedNames, and null return happens consistently)

The dynamic modules proposal adjustment for this is at https://github.com/nodejs/dynamic-modules/pull/11/files, where namespaces are always finalized at https://github.com/nodejs/dynamic-modules/pull/11/files#diff-3540caefa502006d8a33cb1385720803R176.

Sorry to drag this one out, have been on and off it over the weekend - would value feedback on the above before a final merge!

[jdalton]

I'm not a fan of making export * from "cjs" throw.
Please see my comment nodejs/dynamic-modules#11 (comment).

[guybedford]

As discussed in the modules meeting, I'm going ahead with merging this into the TC39 PR for dynamic modules, while we can continue to discuss alternative approaches.