<p dir="auto">What is the general sentiment on having the <code class="notranslate">deno-cli</code> crate producing a <code class="notranslate">lib</code> that can be imported by other projects? I think that taking this path would also help making this module lighter - for instance, subproject like the LSP could become a separate crate consuming the <code class="notranslate">deno-cli</code> module, etc.</p>
<p dir="auto">I'm working on a project where I'd like to instantiate multiple instances of the full Deno runtime from within Rust code. Because the <code class="notranslate">cli</code> package only provides a binary, that isn't currently possible. I'd like to avoid the inefficiencies of shelling out to multiple separate Deno processes, and instead spin them up in Rust threads.</p>
<p dir="auto">Adding a <code class="notranslate">[lib]</code> target to <code class="notranslate">Cargo.toml</code> in the <code class="notranslate">cli</code> package would fix this, but it would probably require changes to the package to expose a Rust API with all of the CLI options.</p>