`import(specifier)` (with `await` or `.then()`) now returns a Promise that
fulfills with the imported module's namespace, instead of rejecting with
"dynamic import is not yet supported at runtime".
A live interpreter holds `&mut env`, so the module can't be evaluated
synchronously inside the DynamicImport opcode — and dynamic import is async by
design anyway. So the opcode resolves the specifier (referrer = the module's
URL, now preserved on the module generator across `await` suspensions so a
second import() after a resume still resolves), creates the Promise, and queues
(url, promise_id) via a new `__enqueue_dynamic_import__` host hook. The web_api
facade drains the queue when the VM is idle (settle_dynamic_imports): it
fetches + evaluates each module through the existing run_module and settles the
Promise, looping with the microtask drain so a dynamically-imported module that
itself uses import() is handled. An already-loaded module resolves from the
registry without re-fetching (new JsVm/JsEngine::module_namespace). Bad
specifiers and fetch failures reject the Promise.
Documented limitations: import() referrer inside a non-module-top-level
function is best-effort (absolute specifiers always resolve); draining needs a
network stack, so import() runs on the page-load/script path that has one.
Tests: web_api facade (dynamic import resolves to namespace incl. named+default
exports; missing module rejects). Verified end-to-end via render: destructured
`await import()`, `.then()`-based import, and fetch-failure rejection. just ci
green; Test262 876/1050.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Zachary D. Rowitsch
e0285d8116