Support third-party modules

[kriskowal]

The loadHook returns a static module record. To support linkage with third-party modules including JSON, WASM, and (caveat emptor) CommonJS, extend the loadHook return type to either a static module record or a static module interface.

Objects implementing the static module interface:

• may provide an imports array, with import specifiers for shallow dependencies
• may provide an exports array, containing identifier names
• may provide an reexports object, keyed by import specifier, to either the string "*" or object that maps from imported identifier to exported identifier. The sentinel value "*" indicates that all names are reexported without alteration.
• may provide an async boolean, indicating whether the module initializer runs asynchronously and returns a promise.
• must provide an initialize function that
  • may accept an exports object. (TBD the nature of this object may be as free as an ordinary object, and it is not the module exports namespace exotic object. The module exports namespace exotic object must? be a proxy of this mutable object.)
  • may accept a compartment object.
  • may accept a resolvedImports object, mapping import specifiers to full specifiers in the context of the given compartment.
  • must return a promise if and only if the async field is truthy.

The initializer may call the compartment.import and compartment.importNow functions for any of the values of the resolvedImports object and expect to get the corresponding namespace object without fail.

[devsnek]

this sounds like we should absorb SyntheticModule from webidl

[Jack-Works]

Looks like already solved

[kriskowal]

Thanks @devsnek. I heard @guybedford say SyntheticModule recently and have been trying to puzzle out whether it means the same thing as what I’m calling ThirdPartyStaticModuleRecord in the current draft. Story checks out: spiritually serve the same role. I am considering renaming this to SyntheticStaticModuleRecord.

The synthetic static module record in our current draft is able to do everything a StaticModuleRecord can do, but depending on how you hold it, might not participate in live bindings properly. There’s no notification API for when a property of the module environment record changes, so the synthesis needs to reach for these properties lazily to observe late bindings.

[Jack-Works]

There’s no notification API for when a property of the module environment record changes, so the synthesis needs to reach for these properties lazily to observe late bindings.

That is what happened in real ES Module so I think it is OK.

import a from 'b'
// no notification when a changed

[kriskowal]

@devsnek or @guybedford If you could share a good reference to WebIDL’s definition of SyntheticModule, I’d be much obliged. I’m not sure where to look and search is all noise.

[devsnek]

I'm not sure where it exists these days but there is a copy of it here https://tc39.es/proposal-json-modules/

[gibson042]

If you could share a good reference to WebIDL’s definition of SyntheticModule, I’d be much obliged. I’m not sure where to look and search is all noise.

It was removed from Web IDL a couple years ago without explanation by whatwg/webidl@5021df4 . The HTML spec currently includes (normative!) links of "Synthetic Module Record" to TC39 proposal-json-modules for CSS module scripts and JSON module scripts.