The missing ability in the new spec (2): ES Module hook

[Jack-Works]

It's important to hook the imports to archive the virtualization

In the old API, it is possible to do this via code transformation by the rewrite hook (#243).
Based on the old API (which have no support on ES Module), I created a wrapper (https://github.com/DimensionDev/webextension-polyfill/blob/master/src/realms.ts) to transform all ES Module into SystemJS format

Raw ESM code => SystemJSRealm (subclass) => (Transform into SystemJS) => (passed into Realm)

My SystemJSRealm supports ESModule, dynamic import, and import.meta based on the old Realm API.
In the new Realm, the new Realm#import() API makes ES Module becomes the first-class citizen but I am no longer be able to do the things in the old Realms API.

I propose to add the following hooks:

• HostFinalizeImportMeta hook: tc39/proposal-realms#245
• HostResolveModuleSpecifier hook: tc39/proposal-realms#246
• FetchSourceText hook: tc39/proposal-realms#247
• ExportRecord hook: tc39/proposal-realms#248

Clarify: The order IMO should be:

• If ExportRecord hook returns a result, use it as the Module record.
• • Use case: Polyfilling built-in modules like fs, path, or std:....
• • Use case: Able to support WASM module, CSS module, ...etc
• Then, HostResolveModuleSpecifier hook.
• • Use case: Transform absolute import lodash into the host supported path https://cdn.pika.dev/lodash
• Then, FetchSourceText hook.
• • Use case: Speed up the fetch process with cache?
• • Use case: Fetch and modify the source text before execution
• Finally, HostFinalizeImportMeta hook
• • Use case: Polyfill on new import.meta property

[erights]

Hi @Jack-Works,

Awhile back we had a Realms proposal that was doing too much with a single abstraction. We have since split this into separate proposals for Realms (this one), Compartments https://github.com/tc39/proposal-compartments , and SES https://github.com/tc39/proposal-ses .

https://www.youtube.com/watch?v=pMyGLmfgU5A&list=PLzDw4TTug5O3vIAd4IR1Gp5t_46co_dv9 is a good explanation of Compartments after it was separated from Realms but before it was separated from SES. However, almost all of this explanation remains valid.

The Realms proposal now is only about creating a new set of primordial intrinsics. The Compartments proposal is about customizing execution / evaluation within a Realm. This involves controlling three "namespaces" that provide the context for evaluation -- globals, imports, host hooks. Please re-file these issues there, as is relevant to the state of the Compartments proposal.

Note that many of the host hook issues may be delayed to yet another follow-on proposal. But all the hooks needed for manipulating module importing behavior will remain in the Compartments proposal.

[leobalter]

@erights we can also transfer the issue directly on GitHub. I agree this might also be in the context for Compartments.

[erights]

Please do. Thanks.

[Jack-Works]

The current Compartment API can do all of those things besides source text modification