ffa75be480
The WebAssembly streaming APIs used to be enabled, but used to take buffer sources as their first argument (see #6154 and #7259). This change re-enables them, requiring a Promise<Response> instead, as well as enabling asynchronous compilation of WebAssembly modules. |
||
---|---|---|
.. | ||
examples | ||
00_primordials.js | ||
01_core.js | ||
02_error.js | ||
async_cancel.rs | ||
async_cell.rs | ||
bindings.rs | ||
Cargo.toml | ||
encode_decode_test.js | ||
error.rs | ||
error_builder_test.js | ||
extensions.rs | ||
flags.rs | ||
gotham_state.rs | ||
icudtl.dat | ||
inspector.rs | ||
internal.d.ts | ||
lib.deno_core.d.ts | ||
lib.rs | ||
module_specifier.rs | ||
modules.rs | ||
normalize_path.rs | ||
ops.rs | ||
ops_builtin.rs | ||
ops_json.rs | ||
README.md | ||
resources.rs | ||
runtime.rs | ||
serialize_deserialize_test.js |
Deno Core Crate
The main dependency of this crate is rusty_v8, which provides the V8-Rust bindings.
This Rust crate contains the essential V8 bindings for Deno's command-line interface (Deno CLI). The main abstraction here is the JsRuntime which provides a way to execute JavaScript.
The JsRuntime implements an event loop abstraction for the executed code that
keeps track of all pending tasks (async ops, dynamic module loads). It is user's
responsibility to drive that loop by using JsRuntime::run_event_loop
method -
it must be executed in the context of Rust's future executor (eg. tokio, smol).
In order to bind Rust functions into JavaScript, use the Deno.core.opSync()
and Deno.core.opAsync()
functions to trigger the "op_fn" callback in
JsRuntime::register_op
on Rust side. A conventional way to handle "op_fn"
callbacks is to use the op_sync
and op_async
functions.
Documentation for this crate is thin at the moment. Please see hello_world.rs and http_bench_json_ops.rs as examples of usage.
TypeScript support and lots of other functionality are not available at this layer. See the CLI for that.