Idiomatic injection of modules into deno_runtime/deno_core

[cd-work]

I'd like to include a TypeScript/JavaScript module into my embedded deno runtime (currently using deno_runtime), so consumers can use this module through an import without having to ship it separately through a remote/filesystem source. Using it through a globally available API like Deno.stuff would be fine too.

One way I've figured out this can be done is by loading this module from the module loader, by detecting the module specifier and instead of loading a module from the filesystem, replacing it with a module generated from include_str.

I also know that it's possible to write extensions in JavaScript and many of deno's APIs (like console) seem to be using that functionality. However I was not able to find its usage clearly documented anywhere. As far as I can tell, console is only available publicly in deno_runtime, because the CLI's snapshot is loaded at startup? It doesn't seem like this startup snapshot can be overwritten.

Loading JavaScript extensions conventionally seems to be done with ExtensionBuilder::js, but accessing that code seems to be more difficult. Most JS extensions built by Deno seem to be interacting with things like Deno.__bootstrap and exporting things on globalThis, but how exactly that works isn't clear to me. ES5 module importing something created through ExtensionBuilder::js is obviously not possible, because my module loader wouldn't know about this. So how would one generally interact with a JavaScript extension, is it necessary to do something like this to get it to work at all?

My first approach obviously works, but I'd like to know what the idiomatic resolution to this would be. There might also be something I completely missed, so please let me know if that is the case. And I'd really appreciate some clearing up on ExtensionBuilder::js extensions because I haven't been able figure those out at all.