feat: lazy loaded esm sources #263
Conversation
|
|
|
Pretty much stuck on how to handle primordials now... EDIT: Spitballing here, but maybe we could add EDIT2: After some more thinking, I think |
|
Opened #363 to solve the primordials problem. |
This commit adds "ext:core/mod.js" built-in ES module that reexports "core", "internals" and "primordials" properties of the "globalThis.__bootstrap" namespace. This is very convenient for embedders that author runtime code using ES modules instead of scripts, because it allows to import these props directly instead of capturing "globalThis.__bootstrap" namespace. To achieve that a new "ModuleMap::lazy_load_es_module_from_code" method was added that accepts a specifier and source code; instantiates and evaluates the provided code as ES module. This will be very useful for #263 and denoland/deno#21422.
| "setup.js", | ||
| r#" | ||
| Deno.core.print("1\n"); | ||
| const module = Deno.core.ops.op_lazy_load_esm("ext:test_ext/lazy_loaded.js"); |
There was a problem hiding this comment.
Can we add this as built-in on core? Maybe Deno.core.importSync
There was a problem hiding this comment.
I'd rather not - I think it's good that it's in ops and not too obvious. User code can still execute it (but the blast radius is really limited), and I think ops a bit more obscure than APIs on Deno.core.
|
This looks good to me other than some minor items. |
This commit adds a new lazy to lazy load internal runtime code
authored in ES modules using "op_lazy_load_esm" op.
The code needs to embedded in the binary to be eliglble for lazy-loading,
and that can be achieved using "lazy_loaded_esm" option on the
"extension!" macro.
Prerequisite for denoland/deno#20812