You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. Append { [[Key]]: _key_, [[Value]]: _value_ } to _assertions_.
104
104
1. Sort _assertions_ by the code point order of the [[Key]] of each element. NOTE: This sorting is observable only in that hosts are prohibited from distinguishing among assertions by the order they occur in.
105
105
1. Let _moduleRequest_ be a new ModuleRequest Record { [[Specifier]]: _specifierString_, [[Assertions]]: _assertions_ }.
<p>HostResolveImportedModule is an implementation-defined abstract operation that provides the concrete Module Record subclass instance that corresponds to <del>the |ModuleSpecifier| String, _specifier_,</del><ins>the ModuleRequest Record_moduleRequest_</del> occurring within the context of the script or module represented by the Script Record or Module Record _referencingScriptOrModule_. _referencingScriptOrModule_ may also be *null*, if the resolution is being performed in the context of an <emu-xrefhref="#sec-import-calls">`import()`</emu-xref> expression, and there is no active script or module at that time.</ins></p>
<p>The host-defined abstract operation HostLoadImportedModule takes arguments _referrer_ (a Script Record, a Cyclic Module Record, or a Realm Record), <del>_specifier_ (a String)</del><ins>_moduleRequest_ (a ModuleRequest Record)</ins>, _hostDefined_ (anything), and _payload_ (a ModuleLoadState Record) and returns ~unused~.</p>
126
127
127
128
<emu-note>
128
-
<p>An example of when _referencingScriptOrModule_ can be *null* is in a web browser host. There, if a user clicks on a control given by</p>
129
+
<p>An example of when _referrer_ can be a Realm Record is in a web browser host. There, if a user clicks on a control given by</p>
<p>there will be no active script or module at the time the <emu-xrefhref="#sec-import-calls">`import()`</emu-xref> expression runs. More generally, this can happen in any situation where the host pushes execution contexts with *null* ScriptOrModule components onto the execution context stack.</p>
133
134
</emu-note>
134
135
135
-
<p>The implementation of HostResolveImportedModule must conform to the following requirements:</p>
136
+
<p>An implementation of HostLoadImportedModule must conform to the following requirements:</p>
136
137
<ul>
137
138
<li>
138
-
The normal return value must be an instance of a concrete subclass of Module Record.
139
+
The host environment must perform FinishLoadingImportedModule(_referrer_, <del>_specifier_</del><ins>_moduleRequest_</ins>, _payload_, _result_), where _result_ is either a normal completion containing the loaded Module Record or a throw completion, either synchronously or asynchronously.
139
140
</li>
140
141
<li>
141
-
If a Module Record corresponding to the pair _referencingScriptOrModule_, <del>_specifier_</del>, <ins>_moduleRequest_</ins> does not exist or cannot be created, an exception must be thrown.
142
-
</li>
143
-
<li>
144
-
Each time this operation is called with a specific _referencingScriptOrModule_, <del>_specifier_ pair</del> <ins>_moduleRequest_.[[Specifier]], _moduleRequest_.[[Assertions]] triple</ins> as arguments it must return the same Module Record instance if it completes normally.
142
+
<p>If this operation is called multiple times with the same <del>(_referrer_, _specifier_) pair</del><ins>(_referrer_, _moduleRequest_.[[Specifier]], _moduleRequest_.[[Assertions]]) triple</ins> and it performs FinishLoadingImportedModule(_referrer_, <del>_specifier_</del><ins>_moduleRequest_</ins>, _payload_, _result_) where _result_ is a normal completion, then it must perform FinishLoadingImportedModule(_referrer_, <del>_specifier_</del><ins>_moduleRequest_</ins>, _payload_, _result_) with the same _result_ each time.</p>
143
+
144
+
<p><ins>It is recommended but not required that implementations additionally conform to the following stronger constraint:</ins></p>
145
145
<ul>
146
146
<li>
147
-
It is recommended but not required that implementations additionally conform to the following stronger constraint: each time this operation is called with a specific _referencingScriptOrModule_, _moduleRequest_.[[Specifier]] pair as arguments it must return the same Module Record instance if it completes normally.
147
+
<ins>If this operation is called multiple times with the same (_referrer_, _moduleRequest_.[[Specifier]]) pair and it performs FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_) where _result_ is a normal completion, then it must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_) with the same _result_ each time.</ins>
148
148
</li>
149
149
</ul>
150
150
</li>
151
151
<li>
152
152
<ins>_moduleRequest_.[[Assertions]] must not influence the interpretation of the module or the module specifier; instead, it may be used to determine whether the algorithm completes normally or with an abrupt completion.</ins>
153
153
</li>
154
+
<li>
155
+
The operation must treat _payload_ as an opaque value to be passed through to FinishLoadingImportedModule.
156
+
</li>
154
157
</ul>
155
-
<p>Multiple different _referencingScriptOrModule_, <del>_specifier_</del> <ins>_moduleRequest_.[[Specifier]]</ins> pairs may map to the same Module Record instance. The actual mapping semantic is implementation-defined but typically a normalization process is applied to _specifier_ as part of the mapping process. A typical normalization process would include actions such as alphabetic case folding and expansion of relative and abbreviated path specifiers.</p>
158
+
159
+
<p>The actual process performed is host-defined, but typically consists of performing whatever I/O operations are necessary to load the appropriate Module Record. Multiple different (_referrer_, <del>_specifier_</del><ins>_moduleRequest_.[[Specifier]]</ins>) pairs may map to the same Module Record instance. The actual mapping semantic is host-defined but typically a normalization process is applied to <del>_specifier_</del><ins>_moduleRequest_.[[Specifier]]</ins> as part of the mapping process. A typical normalization process would include actions such as expansion of relative and abbreviated path specifiers.</p>
156
160
157
161
<emu-notetype=editor>
158
162
<p>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.</p>
<p>HostImportModuleDynamically is an implementation-defined abstract operation that performs any necessary setup work in order to make available the module corresponding to the <del>|ModuleSpecifier| String, _specifier_,</del><ins>ModuleRequest Record _moduleRequest_</ins> occurring within the context of the script or module represented by the Script Record or Module Record _referencingScriptOrModule_. (_referencingScriptOrModule_ may also be *null*, if there is no active script or module when the <emu-xrefhref="#sec-import-calls">`import()`</emu-xref> expression occurs.) It then performs FinishDynamicImport to finish the dynamic import process.</p>
172
-
173
-
174
-
<p>The implementation of HostImportModuleDynamically must conform to the following requirements:</p>
175
-
176
-
<ul>
177
-
<li>
178
-
The abstract operation must always complete normally with *undefined*. Success or failure must instead be signaled as discussed below.
179
-
</li>
180
-
<li>
181
-
The host environment must conform to one of the two following sets of requirements:
182
-
<dl>
183
-
<dt>Success path</dt>
184
-
185
-
<dd>
186
-
<ul>
187
-
<li>At some future time, the host environment must perform FinishDynamicImport(_referencingScriptOrModule_, <del>_specifier_,</del> <ins>_moduleRequest_</ins>, _promiseCapability_, NormalCompletion(*undefined*)).</li>
188
-
189
-
<li>Any subsequent call to HostResolveImportedModule after FinishDynamicImport has completed, given the arguments _referencingScriptOrModule_, and <del>_specifier_</del> <ins>_moduleRequest_</ins> must complete normally.</li>
190
-
191
-
<li>The completion value of any subsequent call to HostResolveImportedModule after FinishDynamicImport has completed, given the arguments _referencingScriptOrModule_, and <del>_specifier_,</del> <ins>_moduleRequest_</ins> must be a module which has already been evaluated, i.e. whose Evaluate concrete method has already been called and returned a normal completion.</li>
192
-
</ul>
193
-
</dd>
194
-
195
-
<dt>Failure path</dt>
196
-
197
-
<dd>
198
-
<ul>
199
-
<li>At some future time, the host environment must perform FinishDynamicImport(_referencingScriptOrModule_, <del>_specifier_,</del> <ins>_moduleRequest_,</ins> _promiseCapability_, an abrupt completion), with the abrupt completion representing the cause of failure.</li>
200
-
</ul>
201
-
</dd>
202
-
</dl>
203
-
</li>
204
-
<li>
205
-
If the host environment takes the success path once for a given _referencingScriptOrModule_, <del>_specifier_,</del> <ins>_moduleRequest_</ins> pair, it must always do so for subsequent calls.
206
-
</li>
207
-
<li>
208
-
The operation must not call _promiseCapability_.[[Resolve]] or _promiseCapability_.[[Reject]], but instead must treat _promiseCapability_ as an opaque identifying value to be passed through to FinishDynamicImport.
209
-
</li>
210
-
</ul>
211
-
212
-
<p>The actual process performed is implementation-defined, but typically consists of performing whatever I/O operations are necessary to allow HostResolveImportedModule to synchronously retrieve the appropriate Module Record, and then calling its Evaluate concrete method. This might require performing similar normalization as HostResolveImportedModule does.</p>
<p>The abstract operation FinishDynamicImport takes arguments _referencingScriptOrModule_, <del>_specifier_,</del> <ins>_moduleRequest_ (a ModuleRequest Record),</ins> _promiseCapability_, and _completion_. FinishDynamicImport completes the process of a dynamic import originally started by an <emu-xrefhref="#sec-import-calls">`import()`</emu-xref> call, resolving or rejecting the promise returned by that call as appropriate according to _completion_. It is performed by host environments as part of HostImportModuleDynamically. It performs the following steps when called:</p>
<p>The abstract operation FinishLoadingImportedModule takes arguments _referrer_ (a Script Record, a Cyclic Module Record, or a Realm Record), <del>_specifier_ (a String)</del><ins>_moduleRequest_ (a ModuleRequest Record)</ins>, _state_ (a ModuleLoadState Record), and _result_ (either a normal completion containing a Module Record or a throw completion) and returns ~unused~.</p>
219
176
220
177
<emu-alg>
221
-
1. If _completion_ is an abrupt completion, then perform ! Call(_promiseCapability_.[[Reject]], *undefined*, « _completion_.[[Value]] »).
178
+
1. If _result_ is a normal completion, then
179
+
1. If _referrer_.[[LoadedModules]] contains a Record _record_ such that _record_.[[Specifier]] is _moduleRequest_.[[Specifier]] <ins>and AssertionsEqual(_record_.[[Assertions]], _moduleRequest_.[[Assertions]]) is *true*</ins>, then
180
+
1.Assert:_record_.[[Module]] is _result_.[[Value]].
181
+
1. Else, add Record { [[Specifier]]: _moduleRequest_.[[Specifier]], <ins>[[Assertions]]: _moduleRequest_.[[Assertions]]</ins>, [[Module]]: _result_.[[Value]] } to _referrer_.[[LoadedModules]].
<p>The description of the [[LoadedModules]] field of Realm Record, Script Record, and Cyclic Module Record should be updated to include the [[Assertions]] field.</p>
<p>The abstract operation AssertionsEqual takes arguments _left_ and _right_ (two Lists of Records { [[Key]]: a String, [[Value]]: a String }), and returns a Boolean.</p>
195
+
196
+
<emu-alg>
197
+
1. If the number of elements in _left_ is not the same as the number of elements in _right_, return *false*.
198
+
1. For each Record { [[Key]], [[Value]] } _r_ of _left_, do
199
+
1. Let _found_ be *false*.
200
+
1. For each Record { [[Key]], [[Value]] } _s_ of _right_, do
201
+
1. If _r_.[[Key]] is _s_.[[Key]] and _r_.[[Value]] is _s_.[[Value]], then
<p>A <dfn>ModuleRequest Record</dfn> represents the request to import a module with given import assertions. It consists of the following fields:</p>
315
-
<emu-tableid="table-cyclic-module-fields"caption="ModuleRequest Record fields">
292
+
<emu-tableid="table-modulerequest-fields"caption="ModuleRequest Record fields">
316
293
<table>
317
294
<tbody>
318
295
<tr>
@@ -558,7 +535,7 @@ <h1>Sample host integration: The Web embedding</h1>
558
535
559
536
<ul>
560
537
<li>The <ahref="https://html.spec.whatwg.org/#module-script">module script</a> would have an additional item, which would be the module type, as a string (e.g., *"json"*), or *undefined* for a JavaScript module.</li>
561
-
<li>HostResolveImportedModule and HostImportModuleDynamically would take a ModuleRequest Record parameter in place of a specifier string, which would be passed down through several abstract operations to reach the <ahref="https://html.spec.whatwg.org/#fetch-a-single-module-script">fetch a single module script</a> algorithm. Somewhere near the entrypoint, if the ModuleRequest Record's [[Assertions]] field has an element _entry_ such that _entry_.[[Key]] is *"type"*, then let _type_ be _entry_.[[Value]]; otherwise let _type_ be *undefined*. If the type is invalid, then an exception is thrown and module loading fails. Otherwise, this will equal the module type, if the module can be successfully fetched with a matching MIME type.</li>
538
+
<li>HostLoadImportedModule would take a ModuleRequest Record parameter in place of a specifier string, which would be passed down through several abstract operations to reach the <ahref="https://html.spec.whatwg.org/#fetch-a-single-module-script">fetch a single module script</a> algorithm. Somewhere near the entrypoint, if the ModuleRequest Record's [[Assertions]] field has an element _entry_ such that _entry_.[[Key]] is *"type"*, then let _type_ be _entry_.[[Value]]; otherwise let _type_ be *undefined*. If the type is invalid, then an exception is thrown and module loading fails. Otherwise, this will equal the module type, if the module can be successfully fetched with a matching MIME type.</li>
562
539
<li>In the <ahref="https://html.spec.whatwg.org/#fetch-the-descendants-of-a-module-script">fetch the descendents of a module script</a> algorithm, when iterating over [[RequestedModules]], the elements are ModuleRequest Records rather than just specifier strings; these Records is passed on to the internal module script graph fetching procedure (which sends it to "fetch a single module script". Other usage sites of [[RequestedModules]] ignore the assertion.</li>
563
540
<li>"Fetch a single module script" would check the assertion in two places:
0 commit comments