[DDSDev]

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!

[beeandapenguin]

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:

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

[fatboy]

Can you tell us a bit about a project you've embedded it in? Was it done to provide a scripting interface to an application? Something else?

[DDSDev]

It was an emacs fork that used TypeScript/Javascript alongside elisp. I am currently in the process of upgrading to deno 1.30.3 right now.