deno_runtime NpmResolver like the CLI?
As far as I can tell, if I want to embed Deno in my Rust application using deno_core and deno_runtime, I would effectively need to implement my own npm: specifier resolution.
https://docs.rs/deno_node/0.76.0/deno_node/trait.NpmResolver.html
I found this trait I can implement, but what I really want is for module imports to just be identical to how they are when running code from the plain Deno CLI.
People seem to say frequently that deno_runtime is the solution for copying the Deno CLI's behavior in a custom executable, but I can't find any existing structures that mimic the module-graph mapping behavior that is included with the CLI, so wouldn't I be better off just forking the CLI code?
NpmResolver in deno_node - Rust
API documentation for the Rust
NpmResolver trait in crate deno_node.4 Replies
it looks like the trait is only implemented in the cli/ directory in the deno repository
and even if I just do the work and implement my own npm resolver, surely there's other things that I'd later find only exist in cli/ and not runtime/
and surely, if I just add a lib.rs file and make a minimal edit to the Cargo.toml, it'll be easy to keep up with new versions of Deno
I wasn't able to find the answer to your question in the official Deno documentation. However, based on the information you've provided in your message, it seems like you are looking to replicate the module resolution behavior of the Deno CLI within a Rust application using
deno_core and deno_runtime.
The NpmResolver trait you found is indeed meant to be implemented if you want to resolve npm specifiers. If you're looking for a way to handle module imports exactly as the Deno CLI does, without implementing your own resolver, it's true that deno_runtime should provide the necessary functionality, as it aims to offer a high-level runtime environment similar to the Deno CLI.
However, if you can't find an existing structure within deno_runtime that mimics the module-graph mapping behavior of the CLI, forking the CLI code might be a solution, but it's not an ideal one since it could lead to maintenance overhead and divergence from the upstream Deno project.
Please note that this advice is not based on the Deno documentation, and I would advise you to double-check the accuracy of this advice. It might be beneficial to look into the source code of Deno itself or to reach out to the Deno community for more insights on how to achieve the behavior you desire without forking the CLI code.I couldn't find a github issue about this either