The deferred evaluation proposal (https://github.com/tc39/proposal-defer-import-eval) is at Stage 3 in TC39 and starting to be implemented now.
We naturally support this in the ESM integration for deferring WebAssembly evaluation as already tracked in #101, but what we do not support is obtaining access to deferred JS namespaces.
This means that WebAssembly cannot import other modules in a way that indicates their execution should be deferred, like JS will be able to do.
The reason for this is that WebAssembly has no way to get the JS module namespace object itself currently as it only imports named exports directly.
For the ESM integration only, the strawman proposal here is to support an import convention form that can be used to obtain the JS module namespace object:
(import "./mod.js" "wasm-js:namespace" (global $ns externref))
(import "./mod.js" "wasm-js:deferred-namespace" (global $ns externref))
In ECMA-262 this directly corresponds to the fact that ~namespace~ and ~deferred-namespace~ are already specified as being supported through the ResolveExport path on the module record, so that we are using the export name position for the convention is not purely a hack, but also matches the underlying specification semantics (see https://tc39.es/proposal-defer-import-eval/#abstract-resolveexport).
The deferred evaluation proposal (https://github.com/tc39/proposal-defer-import-eval) is at Stage 3 in TC39 and starting to be implemented now.
We naturally support this in the ESM integration for deferring WebAssembly evaluation as already tracked in #101, but what we do not support is obtaining access to deferred JS namespaces.
This means that WebAssembly cannot import other modules in a way that indicates their execution should be deferred, like JS will be able to do.
The reason for this is that WebAssembly has no way to get the JS module namespace object itself currently as it only imports named exports directly.
For the ESM integration only, the strawman proposal here is to support an import convention form that can be used to obtain the JS module namespace object:
In ECMA-262 this directly corresponds to the fact that
~namespace~and~deferred-namespace~are already specified as being supported through theResolveExportpath on the module record, so that we are using the export name position for the convention is not purely a hack, but also matches the underlying specification semantics (see https://tc39.es/proposal-defer-import-eval/#abstract-resolveexport).