The abstract operation ModuleRequestsEqual takes arguments x (a ModuleRequest Record or a LoadedModuleRequest Record) and y (a ModuleRequest Record or a LoadedModuleRequest Record) and returns a Boolean. It performs the following steps when called:

1. If x.[[Specifier]] is not y.[[Specifier]], return false.
2. Let xAttrs be x.[[Attributes]].
3. Let yAttrs be y.[[Attributes]].
4. Let xAttrsCount be the number of elements in xAttrs.
5. Let yAttrsCount be the number of elements in yAttrs.
6. If xAttrsCount ≠ yAttrsCount, return false.
7. For each ImportAttribute Record xAttr of xAttrs, do
   1. If yAttrs does not contain an ImportAttribute Record yAttr such that xAttr.[[Key]] is yAttr.[[Key]] and xAttr.[[Value]] is yAttr.[[Value]], return false.
8. Return true.

The abstract operation EvaluateModuleSync takes argument module (a Module Record) and returns either a normal completion containing unused or a throw completion. It synchronously evaluates module, provided that the caller guarantees that module's evaluation will return an already settled promise. It performs the following steps when called:

1. Assert: module is not a Cyclic Module Record.
2. Let promise be module.Evaluate().
3. Assert: promise.[[PromiseState]] is either fulfilled or rejected.
4. If promise.[[PromiseState]] is rejected, then
   1. If promise.[[PromiseIsHandled]] is false, perform HostPromiseRejectionTracker(promise, "handle").
   2. Set promise.[[PromiseIsHandled]] to true.
   3. Throw promise.[[PromiseResult]].
5. Return unused.

The following are the concrete methods for Cyclic Module Record that implement the corresponding Module Record abstract methods defined in Table 39.

This non-normative section gives a series of examples of the linking and evaluation of a few common module graphs, with a specific focus on how errors can occur.

First consider the following simple module graph:

Let's first assume that there are no error conditions. When a host first calls A.LoadRequestedModules(), this will complete successfully by assumption, and recursively load the dependencies of B and C as well (respectively, C and none), and then set A.[[Status]] = B.[[Status]] = C.[[Status]] = unlinked. Then, when the host calls A.Link(), it will complete successfully (again by assumption) such that A.[[Status]] = B.[[Status]] = C.[[Status]] = linked. These preparatory steps can be performed at any time. Later, when the host is ready to incur any possible side effects of the modules, it can call A.Evaluate(), which will complete successfully, returning a Promise resolving to undefined (again by assumption), recursively having evaluated first C and then B. Each module's [[Status]] at this point will be evaluated.

Consider then cases involving linking errors, after a successful call to A.LoadRequestedModules(). If InnerModuleLinking of C succeeds but, thereafter, fails for B, for example because it imports something that C does not provide, then the original A.Link() will fail, and both A and B's [[Status]] remain unlinked. C's [[Status]] has become linked, though.

Finally, consider a case involving evaluation errors after a successful call to Link(). If InnerModuleEvaluation of C succeeds but, thereafter, fails for B, for example because B contains code that throws an exception, then the original A.Evaluate() will fail, returning a rejected Promise. The resulting exception will be recorded in both A and B's [[EvaluationError]] fields, and their [[Status]] will become evaluated. C will also become evaluated but, in contrast to A and B, will remain without an [[EvaluationError]], as it successfully completed evaluation. Storing the exception ensures that any time a host tries to reuse A or B by calling their Evaluate() method, it will encounter the same exception. (Hosts are not required to reuse Cyclic Module Records; similarly, hosts are not required to expose the exception objects thrown by these methods. However, the specification enables such uses.)

Now consider a different type of error condition:

In this scenario, module A declares a dependency on some other module, but no Module Record exists for that module, i.e. HostLoadImportedModule calls FinishLoadingImportedModule with an exception when asked for it. This could occur for a variety of reasons, such as the corresponding resource not existing, or the resource existing but ParseModule returning some errors when trying to parse the resulting source text. Hosts can choose to expose the cause of failure via the completion they pass to FinishLoadingImportedModule. In any case, this exception causes a loading failure, which results in A's [[Status]] remaining new.

The difference here between loading, linking and evaluation errors is due to the following characteristic:

• Evaluation must be only performed once, as it can cause side effects; it is thus important to remember whether evaluation has already been performed, even if unsuccessfully. (In the error case, it makes sense to also remember the exception because otherwise subsequent Evaluate() calls would have to synthesize a new one.)
• Linking, on the other hand, is side-effect-free, and thus even if it fails, it can be retried at a later time with no issues.
• Loading closely interacts with the host, and it may be desirable for some of them to allow users to retry failed loads (for example, if the failure is caused by temporarily bad network conditions).

Now, consider a module graph with a cycle:

Here we assume that the entry point is module A, so that the host proceeds by calling A.LoadRequestedModules(), which performs InnerModuleLoading on A. This in turn calls InnerModuleLoading on B and C. Because of the cycle, this again triggers InnerModuleLoading on A, but at this point it is a no-op since A's dependencies loading has already been triggered during this LoadRequestedModules process. When all the modules in the graph have been successfully loaded, their [[Status]] transitions from new to unlinked at the same time.

Then the host proceeds by calling A.Link(), which performs InnerModuleLinking on A. This in turn calls InnerModuleLinking on B. Because of the cycle, this again triggers InnerModuleLinking on A, but at this point it is a no-op since A.[[Status]] is already linking. B.[[Status]] itself remains linking when control gets back to A and InnerModuleLinking is triggered on C. After this returns with C.[[Status]] being linked, both A and B transition from linking to linked together; this is by design, since they form a strongly connected component. It's possible to transition the status of modules in the same SCC at the same time because during this phase the module graph is traversed with a depth-first search.

An analogous story occurs for the evaluation phase of a cyclic module graph, in the success case.

Now consider a case where A has a linking error; for example, it tries to import a binding from C that does not exist. In that case, the above steps still occur, including the early return from the second call to InnerModuleLinking on A. However, once we unwind back to the original InnerModuleLinking on A, it fails during InitializeEnvironment, namely right after C.ResolveExport(). The thrown SyntaxError exception propagates up to A.Link, which resets all modules that are currently on its stack (these are always exactly the modules that are still linking). Hence both A and B become unlinked. Note that C is left as linked.

Alternatively, consider a case where A has an evaluation error; for example, its source code throws an exception. In that case, the evaluation-time analogue of the above steps still occurs, including the early return from the second call to InnerModuleEvaluation on A. However, once we unwind back to the original InnerModuleEvaluation on A, it fails by assumption. The exception thrown propagates up to A.Evaluate(), which records the error in all modules that are currently on its stack (i.e., the modules that are still evaluating) as well as via [[AsyncParentModules]], which form a chain for modules which contain or depend on top-level await through the whole dependency graph through the AsyncModuleExecutionRejected algorithm. Hence both A and B become evaluated and the exception is recorded in both A and B's [[EvaluationError]] fields, while C is left as evaluated with no [[EvaluationError]].

Lastly, consider a module graph with a cycle, where all modules complete asynchronously:

Loading and linking happen as before, and all modules end up with [[Status]] set to linked.

Calling A.Evaluate() calls InnerModuleEvaluation on A, B, and D, which all transition to evaluating. Then InnerModuleEvaluation is called on A again, which is a no-op because it is already evaluating. At this point, D.[[PendingAsyncDependencies]] is 0, so ExecuteAsyncModule(D) is called and we call D.ExecuteModule with a new PromiseCapability tracking the asynchronous execution of D. We unwind back to the InnerModuleEvaluation on B, setting B.[[PendingAsyncDependencies]] to 1 and B.[[AsyncEvaluationOrder]] to 1. We unwind back to the original InnerModuleEvaluation on A, setting A.[[PendingAsyncDependencies]] to 1. In the next iteration of the loop over A's dependencies, we call InnerModuleEvaluation on C and thus on D (again a no-op) and E. As E has no dependencies and is not part of a cycle, we call ExecuteAsyncModule(E) in the same manner as D and E is immediately removed from the stack. We unwind once more to the InnerModuleEvaluation on C, setting C.[[AsyncEvaluationOrder]] to 3. Now we finish the loop over A's dependencies, set A.[[AsyncEvaluationOrder]] to 4, and remove the entire strongly connected component from the stack, transitioning all of the modules to evaluating-async at once. At this point, the fields of the modules are as given in Table 43.

Field Module	A	B	C	D	E
[[DFSAncestorIndex]]	0	0	0	0	4
[[Status]]	evaluating-async	evaluating-async	evaluating-async	evaluating-async	evaluating-async
[[AsyncEvaluationOrder]]	4	1	3	0	2
[[AsyncParentModules]]	« »	« A »	« A »	« B, C »	« C »
[[PendingAsyncDependencies]]	2 (B and C)	1 (D)	2 (D and E)	0	0

Let us assume that E finishes executing first. When that happens, AsyncModuleExecutionFulfilled is called, E.[[Status]] is set to evaluated and C.[[PendingAsyncDependencies]] is decremented to become 1. The fields of the updated modules are as given in Table 44.

Field Module	C	E
[[DFSAncestorIndex]]	0	4
[[Status]]	evaluating-async	evaluated
[[AsyncEvaluationOrder]]	3	done
[[AsyncParentModules]]	« A »	« C »
[[PendingAsyncDependencies]]	1 (D)	0

D is next to finish (as it was the only module that was still executing). When that happens, AsyncModuleExecutionFulfilled is called again and D.[[Status]] is set to evaluated. Its ancestors available for execution are B (whose [[AsyncEvaluationOrder]] is 1) and C (whose [[AsyncEvaluationOrder]] is 3), thus B will be handled first: B.[[PendingAsyncDependencies]] is decremented to become 0, ExecuteAsyncModule is called on B, and it starts executing. C.[[PendingAsyncDependencies]] is also decremented to become 0, and C starts executing (potentially in parallel to B if B contains an await). The fields of the updated modules are as given in Table 45.

Field Module	B	C	D
[[DFSAncestorIndex]]	0	0	0
[[Status]]	evaluating-async	evaluating-async	evaluated
[[AsyncEvaluationOrder]]	1	3	done
[[AsyncParentModules]]	« A »	« A »	« B, C »
[[PendingAsyncDependencies]]	0	0	0

Let us assume that C finishes executing next. When that happens, AsyncModuleExecutionFulfilled is called again, C.[[Status]] is set to evaluated and A.[[PendingAsyncDependencies]] is decremented to become 1. The fields of the updated modules are as given in Table 46.

Field Module	A	C
[[DFSAncestorIndex]]	0	0
[[Status]]	evaluating-async	evaluated
[[AsyncEvaluationOrder]]	4	done
[[AsyncParentModules]]	« »	« A »
[[PendingAsyncDependencies]]	1 (B)	0

Then, B finishes executing. When that happens, AsyncModuleExecutionFulfilled is called again and B.[[Status]] is set to evaluated. A.[[PendingAsyncDependencies]] is decremented to become 0, so ExecuteAsyncModule is called and it starts executing. The fields of the updated modules are as given in Table 47.

Field Module	A	B
[[DFSAncestorIndex]]	0	0
[[Status]]	evaluating-async	evaluated
[[AsyncEvaluationOrder]]	4	done
[[AsyncParentModules]]	« »	« A »
[[PendingAsyncDependencies]]	0	0

Finally, A finishes executing. When that happens, AsyncModuleExecutionFulfilled is called again and A.[[Status]] is set to evaluated. At this point, the Promise in A.[[TopLevelCapability]] (which was returned from A.Evaluate()) is resolved, and this concludes the handling of this module graph. The fields of the updated module are as given in Table 48.

Field Module	A
[[DFSAncestorIndex]]	0
[[Status]]	evaluated
[[AsyncEvaluationOrder]]	done
[[AsyncParentModules]]	« »
[[PendingAsyncDependencies]]	0

Alternatively, consider a failure case where C fails execution and returns an error before B has finished executing. When that happens, AsyncModuleExecutionRejected is called, which sets C.[[Status]] to evaluated and C.[[EvaluationError]] to the error. It then propagates this error to all of the AsyncParentModules by performing AsyncModuleExecutionRejected on each of them. The fields of the updated modules are as given in Table 49.

Field Module	A	C
[[DFSAncestorIndex]]	0	0
[[Status]]	evaluated	evaluated
[[AsyncEvaluationOrder]]	done	done
[[AsyncParentModules]]	« »	« A »
[[PendingAsyncDependencies]]	1 (B)	0
[[EvaluationError]]	empty	C's evaluation error

A will be rejected with the same error as C since C will call AsyncModuleExecutionRejected on A with C's error. A.[[Status]] is set to evaluated. At this point the Promise in A.[[TopLevelCapability]] (which was returned from A.Evaluate()) is rejected. The fields of the updated module are as given in Table 50.

Field Module	A
[[DFSAncestorIndex]]	0
[[Status]]	evaluated
[[AsyncEvaluationOrder]]	done
[[AsyncParentModules]]	« »
[[PendingAsyncDependencies]]	0
[[EvaluationError]]	C's Evaluation Error

Then, B finishes executing without an error. When that happens, AsyncModuleExecutionFulfilled is called again and B.[[Status]] is set to evaluated. GatherAvailableAncestors is called on B. However, A.[[CycleRoot]] is A which has an evaluation error, so it will not be added to the returned sortedExecList and AsyncModuleExecutionFulfilled will return without further processing. Any future importer of B will resolve the rejection of B.[[CycleRoot]].[[EvaluationError]] from the evaluation error from C that was set on the cycle root A. The fields of the updated modules are as given in Table 51.

Field Module	A	B
[[DFSAncestorIndex]]	0	0
[[Status]]	evaluated	evaluated
[[AsyncEvaluationOrder]]	4	1
[[AsyncParentModules]]	« »	« A »
[[PendingAsyncDependencies]]	0	0
[[EvaluationError]]	C's Evaluation Error	empty

The abstract operation ParseModule takes arguments sourceText (a String or a sequence of Unicode code points), realm (a Realm Record), and hostDefined (anything) and returns a Source Text Module Record or a non-empty List of SyntaxError objects. It creates a Source Text Module Record based upon the result of parsing sourceText as a Module. It performs the following steps when called:

1. Let body be ParseText(sourceText, Module).
2. If body is a List of errors, return body.
3. Let requestedModules be the ModuleRequests of body.
4. Let importEntries be the ImportEntries of body.
5. Let importedBoundNames be ImportedLocalNames(importEntries).
6. Let indirectExportEntries be a new empty List.
7. Let localExportEntries be a new empty List.
8. Let starExportEntries be a new empty List.
9. Let exportEntries be the ExportEntries of body.
10. For each ExportEntry Record exportEntry of exportEntries, do
    1. If exportEntry.[[ModuleRequest]] is null, then
       1. If importedBoundNames does not contain exportEntry.[[LocalName]], then
          1. Append exportEntry to localExportEntries.
       2. Else,
          1. NOTE: When exporting a binding or namespace object which was originally imported from another module, the ExportEntry Record is rewritten to match the form it would have if the binding or namespace object had been re-exported directly from the original module rather than imported then exported. This allows conflicts which arise from exporting the same binding or namespace twice under the same name through export * from to be ignored rather than being treated as ambiguous in step 9.e.iii of the ResolveExport concrete method of Source Text Module Records.
          2. Let ie be the element of importEntries whose [[LocalName]] is exportEntry.[[LocalName]].
          3. Append the ExportEntry Record { [[ModuleRequest]]: ie.[[ModuleRequest]], [[ImportName]]: ie.[[ImportName]], [[LocalName]]: null, [[ExportName]]: exportEntry.[[ExportName]] } to indirectExportEntries.
    2. Else if exportEntry.[[ImportName]] is all-but-default, then
       1. Assert: exportEntry.[[ExportName]] is null.
       2. Append exportEntry to starExportEntries.
    3. Else,
       1. Append exportEntry to indirectExportEntries.
11. Let async be body Contains await.
12. Return Source Text Module Record { [[Realm]]: realm, [[Environment]]: empty, [[Namespace]]: empty, [[CycleRoot]]: empty, [[HasTLA]]: async, [[AsyncEvaluationOrder]]: unset, [[TopLevelCapability]]: empty, [[AsyncParentModules]]: « », [[PendingAsyncDependencies]]: empty, [[Status]]: new, [[EvaluationError]]: empty, [[HostDefined]]: hostDefined, [[ECMAScriptCode]]: body, [[Context]]: empty, [[ImportMeta]]: empty, [[RequestedModules]]: requestedModules, [[LoadedModules]]: « », [[ImportEntries]]: importEntries, [[LocalExportEntries]]: localExportEntries, [[IndirectExportEntries]]: indirectExportEntries, [[StarExportEntries]]: starExportEntries, [[DFSAncestorIndex]]: empty }.

Note

An implementation may parse module source text and analyse it for Early Error conditions prior to the evaluation of ParseModule for that module source text. However, the reporting of any errors must be deferred until the point where this specification actually performs ParseModule upon that source text.

The following are the concrete methods for Source Text Module Record that implement the corresponding Module Record abstract methods defined in Table 39.

The following are the concrete methods for Source Text Module Record that implement the corresponding Cyclic Module Record abstract methods defined in Table 41.

The abstract operation CreateDefaultExportSyntheticModule takes argument defaultExport (an ECMAScript language value) and returns a Synthetic Module Record. It creates a Synthetic Module Record whose default export is defaultExport. It performs the following steps when called:

1. Let realm be the current Realm Record.
2. Let setDefaultExport be a new Abstract Closure with parameters (module) that captures defaultExport and performs the following steps when called:
   1. Perform SetSyntheticModuleExport(module, "default", defaultExport).
   2. Return NormalCompletion(unused).
3. Return the Synthetic Module Record { [[Realm]]: realm, [[Environment]]: empty, [[Namespace]]: empty, [[HostDefined]]: undefined, [[ExportNames]]: « "default" », [[EvaluationSteps]]: setDefaultExport }.

The abstract operation ParseJSONModule takes argument source (a String) and returns either a normal completion containing a Synthetic Module Record, or a throw completion. It performs the following steps when called:

1. Let parseResult be ? ParseJSON(source).
2. Return CreateDefaultExportSyntheticModule(parseResult.[[Value]]).

The abstract operation SetSyntheticModuleExport takes arguments module (a Synthetic Module Record), exportName (a String), and exportValue (an ECMAScript language value) and returns unused. It can be used to set or change the exported value for an existing export of a Synthetic Module Record. It performs the following steps when called:

1. Assert: module.[[ExportNames]] contains exportName.
2. Let envRecord be module.[[Environment]].
3. Assert: envRecord is not empty.
4. Perform ! envRecord.SetMutableBinding(exportName, exportValue, true).
5. Return unused.

The following are the concrete methods for Synthetic Module Record that implement the corresponding Module Record abstract methods defined in Table 39.

The host-defined abstract operation HostGetSupportedImportAttributes takes no arguments and returns a List of Strings. It allows host environments to specify which import attributes they support. Only attributes with supported keys will be provided to the host.

An implementation of HostGetSupportedImportAttributes must conform to the following requirements:

• It must return a List of Strings, each indicating a supported attribute.
• Each time this operation is called, it must return the same List with the same contents in the same order.

The default implementation of HostGetSupportedImportAttributes is to return a new empty List.

Note

The purpose of requiring the host to specify its supported import attributes, rather than passing all attributes to the host and letting it then choose which ones it wants to handle, is to ensure that unsupported attributes are handled in a consistent way across different hosts.