Rely on the new modules loading logic instead of a custom hook

[nicolo-ribaudo]

Hi!

This PR includes the spec for import reflection aligned to what I believe is the shared vision we built during the last few months.

PREVIEW HERE

• import module mod from "x" and await import("x", { module: true }) give you a Module object as defined in Layer 0 of the compartments proposal (spec, explainer).
  • the logic for static imports is in all the changes to the ECMAScript Language: Scripts and Modules section;
  • the logic for dynamic imports is in step 6 of EvaluateImportCall (to parse the "options" object) and step 4 of ContinueDynamicImport (to return the Module object).
• import(mod), where mod instanceof Module, links and evaluates the module. This behavior is identically defined in Layer 0 of compartments and in the Module Blocks proposal, but this duplication is necessary to make each proposal usable on its own.
  • this is specified in step 8 of EvaluateImportCall.
• Module.prototype.source gives you "the source object of the module instance". This proposal doesn't define what it is, it only define that it is an object or null. The compartments proposal (layer 0 and layer 2) better define what is is, but tl;dr it's morally a context-free unlinked representation of the module. This proposal needs it so that import module x from "x.wasm"; x.source can give access to the raw WebAssembly.Module object.

Also, this PR is written on top of https://github.com/tc39/ecma262/pull/2905. The ecma262-biblio.json file you see is to ensure proper linking of all the new AOs to that PR, until it's merged.

cc @littledan, @kriskowal and @caridy, who work on other pieces of this modules improvements effort.

[ljharb]

Does your OP encapsulate the entirety of the proposal? Meaning, there's no other semantics than what you've described?

[nicolo-ribaudo]

Yes. Or at least, it (the OP description, and the spec text in this PR) encapsulates the entirety of one of the possible versions of this proposal: the one which leaves less customizations to the host.

[littledan]

An essential aspect of this proposal will be the Wasm+HTML integration specification, where the .source of a Wasm module is the WebAssembly.Module. I suspect that we could do this without requiring the other compartments proposals to complete, just by saying it is undefined for JS modules for now, and returns that particular object for WebAssembly.

[nicolo-ribaudo]

Right now this PR makes it null for JS modules, and mentions WebAssembly.Module in the note of https://nicolo-ribaudo.github.io/proposal-import-reflection/#sec-module.prototype.source.

[nicolo-ribaudo]

Thanks for the review @guybedford! I reverted the normative changes and now I believe that this PR is purely editorial.

I ignored one of your suggestions: instead of tracking the reflection in an _importReflection_: null | ~module~ variable, I used a boolean. This is because an enum doesn't fit well with the concepts from the hooks refactoring and the other proposals: either you want to execute a module or you want to have it not executed (well, other than passing the evaluator attributes to the host).

[nicolo-ribaudo]

With these changes, the proposal works without almost any changes to host specs :)

We just need to rename [[WebAssemblyModule]] to [[ModuleSourceObject]] in https://webassembly.github.io/esm-integration/js-api/index.html#esm-integration.

[nicolo-ribaudo]

@guybedford I just realized that how we store the two type of imports and how we iterate over them is observable, because both modules evaluation order and modules loading order is observable (loading order is currently only observable by SharedWorkers and Node.js loaders API, but with compartments it would also be observable within ECMA-262).

Consider this example:

import module A from "A";
import module B from "B";
import "C";
import "A";
import "D";

With the spec text that I wrote, the loading order is CADB and the execution order is CAD.

I think that the execution order is fine, but the loading order maybe should be ABCD? Wdyt?

[caridy]

With the spec text that I wrote, the loading order is CADB and the execution order is CAD.

I think that the execution order is fine, but the loading order maybe should be ABCD? Wdyt?

I think it should be the one that matches the developer's intuitions, which in this case is ABCD, by just looking at the code.

[guybedford]

It doesn't make a huge difference to users since loads are parallel, but at least from a host consistency perspective, iterating the operations on the imports in pre-order continues to make sense. I think my suggested changes would do that as well?

[nicolo-ribaudo]

I updated the PR to load dependencies in the correct order.

@guybedford and I discussed about adding a note to discourage hosts from pre-loading dependencies in the HostLoadImportedModule hook, since it's also called for import reflections that don't need their dependencies to be loaded. Does this looks good, added as a fourth bullet point to https://ci.tc39.es/preview/tc39/ecma262/sha/24196c3212c3c4ac421e0cf9b002e58fb1445f6d/#sec-HostLoadImportedModule?

<li>
  <p>The host environment should not attempt loading the dependencies of the loaded Module Record.</p>
  <emu-note>
    When using `import module x from "x"`, the dependencies of `"x"` are not immediately needed and may never be needed. If the dependencies of an imported module need to be loaded, it will be done through further calls to HostLoadImportedModule.
  </emu-note>
</li>