Bartek Iwańczuk
Bartek Iwańczuk
More generic solution than #344 and #357. It allows embedders to load any module type they want. Still some rough edges that need to be fixed. I will probably split...
This commit changes how ops defined in "deno_core" crate are exposed to JavaScript code. They are no longer added to "Deno.core.ops", but to "Deno.core.coreOps", to make the distinction between them...
TODO: needed for better error handling in situations like https://github.com/denoland/deno/pull/21764 during runtime
To address https://github.com/denoland/deno_core/issues/134 as well as #521 we need to store information about already snapshotted extensions and ops in the snapshot. It's not clear how to do it efficiently yet...
This will allow to simplify `JsRuntime::init_extension_js` and not require to use async there (ext sources must be provided synchronously anyway).
Closes https://github.com/denoland/deno_core/issues/501
This file is duplicated in `checkin`. Let's bite the bullet and add `transpile` Cargo feature that provides this loader in `core/modules/loaders` so it can be easily reused. _Originally posted by...
Life the least amount of code possible from https://github.com/denoland/deno/tree/main/cli/tools/repl and provide a simple REPL example that can be used to test out code.
At this point we have 3 distinct types of modules that are executed in `deno_core`: - `internal` modules - these are `ext:core/mod.js` and `ext:core/ops` - these modules are provided automatically...
Currently all registered ops are "added" as JavaScript bindings twice: 1. To `Deno.core.ops` module in: https://github.com/denoland/deno_core/blob/ce620969c447d5cd7d7c21e1b95bc120c67142be/core/runtime/bindings.rs#L268-L298 2. To `ext:core/ops` synthetic module in: https://github.com/denoland/deno_core/blob/ce620969c447d5cd7d7c21e1b95bc120c67142be/core/runtime/bindings.rs#L773-L796 We actually need both approaches - the...