Initial Spec #9
Initial Spec #9
Conversation
|
@nicolo-ribaudo I think this spec text is finally ready, I'd be really grateful if you could review when you have a moment. |
spec.emu
Outdated
| 1. Perform ! CreateDataPropertyOrThrow(_import_, *"phase"*, _maybePhaseString_). | ||
| 1. Append _import_ to _imports_. | ||
| 1. Let _importsArray_ be CreateArrayFromList(_imports_). | ||
| 1. Perform ! CreateDataPropertyOrThrow(_metadata_, *"imports"*, _importsArray_). |
There was a problem hiding this comment.
why there is no "exports" list? it is useful if the module has not been initialized yet
There was a problem hiding this comment.
The difficulty in specifying exports is that we only have this information available for modules at runtime usually. So the hooks model doesn't deal with it being processed in any way before.
We could support exports() for JS modules only (eg putting it on ModuleSource.prototype instead of on AbstractModuleSource.prototype).
Alternatively, we could treat it as a special method to be implemented by any concrete cyclic module record implementation.
| 1. <ins>Let _module_ be Completion(HostGetModuleSourceRecord(_specifier_)).</ins> | ||
| 1. <ins>IfAbruptRejectPromise(_module_, _promiseCapability_).</ins> | ||
| 1. <ins>If _module_ is not ~unused~, then</ins> | ||
| 1. <ins>If _module_.[[Realm]] is not equal to current Realm Record, throw a *TypeError* exception.</ins> |
There was a problem hiding this comment.
why we cannot import from another realm?
There was a problem hiding this comment.
As discussed in the meeting this is a placeholder for now, to be further refined in future as a Stage 2.7 question rather than a Stage 2 question, due to the difficulty in specifying this requiring a new spec refactoring.
The spec refactoring in question would be to separate compiled module records from instance module records like Source Text Module, so that we can have a realm-agnostic backing record. We may want to do this refactoring after import attributes merges in July, but before this proposal reaches Stage 2.7.
This implements some initial spec to work through the hooks model.
The spec text here is based to the source phase imports proposal specification, performing a new diff on top of that. More spec text than is needed is included while we work through the integration points.
This currently implements:
HostGetModuleSourceNamehook into aHostGetModuleRecordFromSourcehook.unusedfrom this host hook to still go through ToString. In addition a new error is thrown if the realms do not match, and this seems like it sets a good precedent for future concepts of compartments matching. This came together relatively simply in the model.GetModuleSourcefor a Source Text Module Record, which also includes now an explicit[[ModuleSource]]slot to cache this on cyclic module records, now that we actually have a valid implementation.ModuleSourcebuiltin object extending abstract module sourceAbstractModuleSource.prototype.imports, as well as getters forget AbstractModuleSource.prototype.hasDynamicImport,hasImportMetaandhasTopLevelAwaitOne slightly weird thing about the hooks model is that
HostGetModuleRecordFromSourceapplies to BOTH the localModuleSourceand other types of module source, so there's wording saying "if it's a ModuleSource, it must conform to the abstract operation for ModuleSource that uses the [[SourceTextModuleRecord]] internal slot". I think that gets us the right flexibility but feedback ensuring clarify here would be very welcome.Hopefully this forms a good initial skeleton of the hook model further feedback and discussion.
Follow-up work can then be investigated further:
Rendered Spec: https://guybedford.github.io/proposal-module-instance-imports/build/