Allow /cli to be built as a static library

[DavidDeSimone]

I've had a few conversations with some other users/forkers - I think it would be useful to allow deno cli to be build as a static (or even shared) library via Cargo to allow for applications to embed more Deno functionality. Currently embedders can include deno_core and deno_runtime, which gives a lot of great functionality, but doesn't include some really killer features like the TypeScript compiler, repl, etc.

If this idea were to be executed, my recommendation/suggestion is not to add cli/ as a crate to cargo - I think that would be too much overhead for the core maintainers. Instead, this would target users that just want to run cargo build --lib, or include a local source copy of Deno and then follow up with linking that product into their applications.

[kitsonk]

The biggest challenge I see is that /cli is far from a stable API, and at the moment none of the API are designed to be consumable and certainly aren't ideal for embedding. It isn't that the core maintainers aren't opposed to it. Core, runtime, and the op_crates have all come out of a desire to componentise Deno. We have been talking about breaking out the module graph recently, and that would lead to breaking out the compiling and transpiring of TypeScript.

Lots of this is driven by maturity of approach on how these things are done and the architecture of Deno has evolved.

[DavidDeSimone]

I think this is a good counterpoint, and I understand that the core contributors need to balance API stability with enabling program embedders ease of use.

I think that breaking out TypeScript compilation would cover 98% of the user cases that I have personally, along with the users I've discussed this with.

[caoccao]

I've worked out a PoC deno_cli_lib which allows referencing deno cli as a library at source code level. You are welcome taking a try. And I look forward to your pull requests if you want to enhance it.