Module Ordering Invariants

Bradley Farias

Should Abstract Module Records be "hoistable"

import "a"; // ESM

import "b"; // should "b" ever be allowed to evaluate before "a"

Should Abstract Module Records be "hoistable"

import "b";

import "a";

import "a";

import "b";

Acts equivalent to alternate for some Abstract Module Record "b"

Previous work

• Imperative imports https://github.com/tc39/ecma262/issues/368�
• ASAP vs Deterministic imports https://docs.google.com/document/d/1MJK0zigKbH4WFCKcHsWwFAzpU_DZppEAOpYJlIW7M7E/view�
• 2016 TC39 discussion on CJS https://github.com/rwaldron/tc39-notes/blob/master/es7/2016-09/sept-28.md

Node

• `import()` removes zebra striping w/ CJS

​

• Still does not provide way to live bind against CJS post eval
• Could use Proxy-like implementation to achieve this but that is a breaking change to Node�
• Hoistability comes from investigation into ways to allow "named" exports from CJS `module.exports`
• Diffrent from "Late Binding"

Add invariant explicitly

• https://tc39.github.io/ecma262/#sec-abstract-module-records�
• Add note that the order of Instantiate and Evaluate must not be reordered within the module subgraph starting from the TopLevelModuleEvaluationJob
• Note: the ordering across graphs has never been guaranteed due to races

Invariant

• Add "Note"s to Abstract Module Record?�
• Only intended to instantiate for integration with ESM lifecycle
• Instantiate
• Evaluate�
• Add "Note"s to Source Text Module Record?�
• Order must be preserved
• Difficult to phrase into concrete semantics

Abstract Module Record

• Has their own Instantiate and Evaluate methods�
• Should these be allowed to be called in "hoisted" order?