deno/runtime
Nathan Whitaker 29934d558c
fix(node): Run node compat tests listed in the ignore field (and fix the ones that fail) (#24631)
The intent is that those tests will be executed, but our check that the
files are up to date won't overwrite the contents of the tests. This is
useful when a test needs some manual edits to work.

It turns out we weren't actually running them.

---

This ended up turning into a couple of small bug fixes to get the tests
passing:

- We weren't canonicalizing the exec path properly (it sometimes still
had `..` or `.` in it)
- We weren't accepting strings in `process.exit`

There was one failure I couldn't figure out quickly, so I disabled the
test for now, and filed a follow up issue: #24694
2024-07-24 03:12:08 +00:00
..
examples/extension refactor: remove PermissionsContainer in deno_runtime (#24119) 2024-06-06 23:37:53 -04:00
js Reland "fix: CFunctionInfo and CTypeInfo leaks (#24634)" (#24692) 2024-07-24 02:11:38 +02:00
ops fix(node): Run node compat tests listed in the ignore field (and fix the ones that fail) (#24631) 2024-07-24 03:12:08 +00:00
permissions chore: forward v1.45.3 release commit to main (#24681) 2024-07-23 03:41:40 +02:00
Cargo.toml chore: forward v1.45.3 release commit to main (#24681) 2024-07-23 03:41:40 +02:00
clippy.toml feat(compile): unstable npm and node specifier support (#19005) 2023-05-10 20:06:59 -04:00
code_cache.rs fix: use hash of in-memory bytes only for code cache (#23966) 2024-05-24 10:15:46 -04:00
errors.rs Reland "refactor(fetch): reimplement fetch with hyper instead of reqwest" (#24593) 2024-07-18 01:37:31 +02:00
fmt_errors.rs refactor: extract out runtime::colors to deno_terminal::colors (#22324) 2024-02-07 11:25:14 -05:00
fs_util.rs fix: use hash of in-memory bytes only for code cache (#23966) 2024-05-24 10:15:46 -04:00
inspector_server.rs chore: enable clippy::print_stdout and clippy::print_stderr (#23732) 2024-05-08 22:45:06 -04:00
js.rs refactor: remove snapshotting from deno_runtime (#21794) 2024-01-10 16:30:50 +01:00
lib.rs fix(cli): missing flag for --unstable-process (#24199) 2024-06-13 16:00:38 +03:00
README.md fix (doc): Typo in runtime/README.md (#20020) 2023-12-13 17:24:32 +00:00
shared.rs fix: better handling of npm resolution occurring on workers (#24094) 2024-06-05 17:04:16 +02:00
snapshot.rs fix(ext/node): fix vm memory usage and context initialization (#23976) 2024-06-12 22:32:54 +05:30
tokio_util.rs chore: enable clippy::print_stdout and clippy::print_stderr (#23732) 2024-05-08 22:45:06 -04:00
web_worker.rs Reland "fix: CFunctionInfo and CTypeInfo leaks (#24634)" (#24692) 2024-07-24 02:11:38 +02:00
worker_bootstrap.rs fix(node): support tty.hasColors() and tty.getColorDepth() (#24619) 2024-07-19 12:39:05 +02:00
worker.rs Reland "fix: CFunctionInfo and CTypeInfo leaks (#24634)" (#24692) 2024-07-24 02:11:38 +02:00

deno_runtime crate

crates docs

This is a slim version of the Deno CLI which removes typescript integration and various tooling (like lint and doc). Basically only JavaScript execution with Deno's operating system bindings (ops).

Stability

This crate is built using battle-tested modules that were originally in the deno crate, however the API of this crate is subject to rapid and breaking changes.

MainWorker

The main API of this crate is MainWorker. MainWorker is a structure encapsulating deno_core::JsRuntime with a set of ops used to implement Deno namespace.

When creating a MainWorker implementors must call MainWorker::bootstrap to prepare JS runtime for use.

MainWorker is highly configurable and allows to customize many of the runtime's properties:

  • module loading implementation
  • error formatting
  • support for source maps
  • support for V8 inspector and Chrome Devtools debugger
  • HTTP client user agent, CA certificate
  • random number generator seed

Worker Web API

deno_runtime comes with support for Worker Web API. The Worker API is implemented using WebWorker structure.

When creating a new instance of MainWorker implementors must provide a callback function that is used when creating a new instance of Worker.

All WebWorker instances are descendents of MainWorker which is responsible for setting up communication with child worker. Each WebWorker spawns a new OS thread that is dedicated solely to that worker.