See the explainer for information.
The changes made to this abstract operation in this proposal build on the changes in the import assertions proposal. In order to distingush them, the changes unique to this proposal are labeled as insertions while the changes from import assertions are not labeled.
HostResolveImportedModule is an implementation-defined abstract operation that provides the concrete import()
An example of when referencingScriptOrModule can be
<button type="button" onclick="import('./foo.mjs')">Click me</button>
there will be no active script or module at the time the import()
The implementation of HostResolveImportedModule must conform to the following requirements:
Multiple different referencingScriptOrModule, moduleRequest.[[Specifier]] pairs may map to the same
The above text implies that is recommended but not required that hosts do not use moduleRequest.[[Assertions]] as part of the module cache key. In either case, an exception thrown from an import with a given assertion list does not rule out success of another import with the same specifier but a different assertion list.
Assertions do not affect the contents of the module. Future follow-up proposals may relax this restriction with "evaluator attributes" that would change the contents of the module. There are three possible ways to handle multiple imports of the same module with "evaluator attributes":
It's possible that one of these three options may make sense for a module load, on a case-by-case basis by attribute, but it's worth careful thought before making this choice.
The above text implies that hosts type: "json"
(if it completes normally), but it doesn't prohibit hosts from supporting JSON modules imported with no type specified. Some environments (for example, web browsers) are expected to require assert { type: "json" }
, and environments which want to restrict themselves to a compatible subset would do so as well.
All of the import statements in the module graph that address the same JSON module will evaluate to the same mutable object.
A Synthetic Module Record is used to represent information about a module that is defined by specifications. Its exports are derived from a pair of lists, of string keys and of ECMAScript values. The set of exported names is static, and determined at creation time (as an argument to
In addition to the fields defined in
Field Name | Value Type | Meaning |
---|---|---|
[[ExportNames]] | A | |
[[EvaluationSteps]] | An Abstract Closure | An Abstract Closure that will be performed upon evaluation of the module, taking the |
The abstract operation CreateSyntheticModule creates a
The abstract operation SetSyntheticModuleExport can be used to set or change the exported value for a pre-established export of a
The following are the concrete methods for
The GetExportedNames concrete method of a
It performs the following steps:
The ResolveExport concrete method of a
It performs the following steps:
The Instantiate concrete method of a
It performs the following steps:
The Evaluate concrete method of a
It performs the following steps:
The CreateDefaultExportSyntheticModule abstract operation creates a
The abstract operation ParseJSONModule takes a single argument source which is a String representing the contents of a module.