CoreRabbit•3mo ago

How do I see which ops are registered?

I am trying to understand how the deno_core::op2 macro works. I used deno_runtime back in September 2021 and I remember that I could console.log Deno[Deno.internal].core.ops to see which ops are registered. Back in 2021 I read the deno CLI code and in my own project copied the setup of MainWorker because I wanted setTimeout. Now in 2024 I tried to upgrade the versions of deno_runtime to 0.272 and ran into the limitations of my knowledge. Right now I see that Deno.core.ops exists if you construct a JsRuntime. And I can use Object.getOwnPropertyNames to print out a list of ops to verify that my rust function ended up inside Deno.core.ops And I also see that when I construct a MainWorker like in https://github.com/denoland/deno/blob/main/runtime/examples/extension/main.rs that Deno.core.ops does not exist. And instead it seems like rust function ends up inside the magic import 'ext:core/ops'. - Do I need to be constructing a MainWorker to have setTimeout working? Because when I try making a JsRuntime and load only my extension I see setTimeout is not defined - Is there an explanation of where the extension mechanism puts the javascript symbols? - Does the new way of using ops work by having a bootstrap js or esm that will import from the magic ext:core/ops and then make those rust functions available by assigning to globalThis? Should I be making a wrapper function like I seen in examples, or can I directly assign the op_hello symbol to globalThis?

GitHub

deno/runtime/examples/extension/main.rs at main · denoland/deno

A modern runtime for JavaScript and TypeScript. Contribute to denoland/deno development by creating an account on GitHub.

3 Replies

Deno AI Helper•3mo ago

I wasn't able to find the answer to your question in the official Deno documentation. However, based on the information you've provided, I can offer some general advice that might help you, but please note that this advice is not based on the Deno documentation, and you should double-check the accuracy of the advice given. From your message, it seems like you are trying to understand the changes in the Deno runtime and how ops are registered and used in the newer version of Deno. Here are a few points that might help: 1. If Deno.core.ops is not available when you construct a MainWorker, it could be due to changes in the Deno internals since 2021. The ops might now be encapsulated differently to provide a cleaner separation between the runtime and extensions. 2. For setTimeout to work, you typically need an environment that includes the necessary timers infrastructure. If MainWorker provides this infrastructure in the newer versions of Deno, then you would indeed need to construct a MainWorker to have setTimeout available. 3. The extension mechanism and where it puts the JavaScript symbols might be explained in more detail in the source code or design documents of Deno. Since this is a more in-depth topic, it might not be covered in the basic documentation. 4. Regarding the new way of using ops, it's possible that a bootstrap JavaScript or ESM file is required to import from ext:core/ops and make the Rust functions available on the globalThis. Creating a wrapper function or directly assigning the op symbol to globalThis would depend on the intended design and usage patterns encouraged by the Deno runtime. Since these points are speculative and not based on the official documentation, I recommend looking at the latest examples in the Deno

Deno AI Helper•3mo ago

repository, checking recent pull requests, issues, and the source code to understand the current best practices for using ops and setting up a runtime environment with the necessary features like setTimeout. Additionally, you might want to reach out to the Deno community or contributors for more specific guidance on these changes.

Helpful Links: Deno Docs Roll your own JavaScript runtime Deno Docs Deno 1.32: Enhanced Node.js Compatibility A list of every web API in Deno

CoreRabbit•3mo ago

I found where ext:core/ops comes from. VIRTUAL_OPS_MODULE_NAME in deno_core/core/runtime/jsruntime.rs Found documentation comment

/// Create a synthetic module - `ext:core/ops` - that exports all ops registered
+  /// with the runtime.
+  fn execute_virtual_ops_module(

/// Create a synthetic module - `ext:core/ops` - that exports all ops registered
+  /// with the runtime.
+  fn execute_virtual_ops_module(

When I read this it make me believe that all of the extensions I register will be merged together into ext:core/ops. This makes me think I have to write JS bootstrap script that imports the op and assigns it onto globalThis for every single extension?