See the explainer for information.
Many productions operating on grammar are the same whether or not an
HostResolveImportedModule is an implementation-defined abstract operation that provides the concrete the the 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, specifier 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.
HostImportModuleDynamically is an implementation-defined abstract operation that performs any necessary setup work in order to make available the module corresponding to the import()
The implementation of HostImportModuleDynamically must conform to the following requirements:
The actual process performed is implementation-defined, but typically consists of performing whatever I/O operations are necessary to allow
The abstract operation FinishDynamicImport takes arguments referencingScriptOrModule, specifier, moduleRequest (a import()
HostGetSupportedImportAssertions is a host-defined abstract operation that allows host environments to specify which import assertions they support. Only assertions with supported keys will be provided to the host.
The implementation of HostGetSupportedImportAssertions must conform to the following requrements:
The default implementation of HostGetSupportedImportAssertions is to return an empty
A ModuleRequest Record represents the request to import a module with given import assertions. It consists of the following fields:
Field Name | Value Type | Meaning |
---|---|---|
[[Specifier]] | String | The module specifier |
[[Assertions]] |
a |
The import assertions |
Field Name | Value Type | Meaning |
---|---|---|
[[Status]] |
|
Initially |
[[EvaluationError]] |
An |
A completion of type |
[[DFSIndex]] |
|
Auxiliary field used during Link and Evaluate only.
If [[Status]] is |
[[DFSAncestorIndex]] |
|
Auxiliary field used during Link and Evaluate only. If [[Status]] is |
[[RequestedModules]] |
|
A |
An ImportEntry Record is a
Field Name | Value Type | Meaning |
---|---|---|
[[ModuleRequest]] |
|
|
[[ImportName]] | String |
The name under which the desired binding is exported by the module identified by [[ModuleRequest]]. The value |
[[LocalName]] | String | The name that is used to locally access the imported value from within the importing module. |
The import assertions proposal is intended to give key information about how modules are interpreted to hosts. For the Web embedding and environments which aim to be similar to it, the string is interpreted as the "module type". This is not the primary way the module type is determined (which, on the Web, would be the MIME type, and in other environments may be the file extension), but rather a secondary check which is required to pass for the module graph to load.
In the Web embedding, the following changes would be made to the HTML specification for import assertions:
The module map is keyed by the absolute URL and the type. Initially no other import assertions are supported, so they are not present.