I apricate the time that the deno team has spent having a separation between deno/deno_core/deno_runtime. The deno codebase is well organized and overall high quality.
One issue I've run into as someone who has embedded these libraries into another other project is that there are a lot of really nice features are only available in deno proper (everything under their cli/ directory https://github.com/denoland/deno/tree/main/cli) vice deno_runtime and deno_core. Specifically, typescript is implemented in cli/
A user of runtime or core could just reimplement those features piece meal, however I ended up just forking deno and adding a lib.rs that just exposes the code in cli/ as a library, and it has worked out pretty well for my needs.
Edit: Elsewhere in the thread the author of this blogpost linked another blog post where they describe getting TS without having to use cli - something I will look into!
Agreed, I felt the same when toying with this concept for the first time. I initially thought I could just build directly off of deno_core, but quickly learned there's a lot you'll have to implement. Much of what I perceived as deno is really just the cli crate and other dependencies that feel somewhat "internal". Some examples of things you'll need to implement and reference from the cli I ran into were:
You can wire up some of these other packages or potentially even the CLI itself to avoid re-implementing much of the runtime over again, but it's a heavy dependency for a few crucial utilities that feel like they could exist in more lightweight runtime crates.
At the end of the day, I feel like most people potentially want to offer APIs through the runtime as opposed to a package or framework (think Netlify edge functions, Shopify functions). I wonder if they are reserving this interface for Deno subhosting customers rather than making it more ergonomic for a self hosted runtime. Kind of similar to how the runtime crate injects Deno's Web Platform JS implementations: https://github.com/denoland/deno/tree/main/ext
17 comments
[ 3.9 ms ] story [ 46.9 ms ] threadOne issue I've run into as someone who has embedded these libraries into another other project is that there are a lot of really nice features are only available in deno proper (everything under their cli/ directory https://github.com/denoland/deno/tree/main/cli) vice deno_runtime and deno_core. Specifically, typescript is implemented in cli/
A user of runtime or core could just reimplement those features piece meal, however I ended up just forking deno and adding a lib.rs that just exposes the code in cli/ as a library, and it has worked out pretty well for my needs.
Edit: Elsewhere in the thread the author of this blogpost linked another blog post where they describe getting TS without having to use cli - something I will look into!
1. module loader: https://github.com/denoland/deno/blob/main/cli/module_loader...
2. runtime interfaces (workers): https://github.com/denoland/deno/blob/main/cli/worker.rs
3. invocation of the runtime: https://github.com/denoland/deno/blob/main/cli/tools/run.rs#...
4. permissions: https://github.com/denoland/deno/blob/main/runtime/permissio...
You can wire up some of these other packages or potentially even the CLI itself to avoid re-implementing much of the runtime over again, but it's a heavy dependency for a few crucial utilities that feel like they could exist in more lightweight runtime crates.
At the end of the day, I feel like most people potentially want to offer APIs through the runtime as opposed to a package or framework (think Netlify edge functions, Shopify functions). I wonder if they are reserving this interface for Deno subhosting customers rather than making it more ergonomic for a self hosted runtime. Kind of similar to how the runtime crate injects Deno's Web Platform JS implementations: https://github.com/denoland/deno/tree/main/ext
[0] https://doc.rust-lang.org/book/ [1] https://www.youtube.com/watch?v=8aGhZQkoFbQ
Just yesterday we posted a second part of this post [0] where we add "fetch"-like API and TypeScript transpilation.
Happy to answer your questions.
[0] https://deno.com/blog/roll-your-own-javascript-runtime-pt2