Publish javy-cli to crates.io

[ianmarmour]

I just wanted to follow up on an outstanding request to publish javy-cli to crates as mentioned in this thread. I'm not sure my requirements are exactly the same as the original requester but my use case is having a rust service that executes compilation at runtime and stores the result somewhere to execute later. I believe the code in javy-cli can accomplish most of what I want and I would rather consume it as a library from crates rather then fork it.

Regarding the original thread it was mentioned that we should start a ticket up to discuss different approaches so I'm going ahead with that here. I'm open to helping out with the contribution but I'm interested in hearing what approaches the maintainers think are best.

[saulecabrera]

my use case is having a rust service that executes compilation at runtime and stores the result somewhere to execute later.

If you're willing to have your service spawn a process (e.g., through https://doc.rust-lang.org/std/process/struct.Command.html) then publishing javy-cli to crates.io such that it can be installed, this approach will probably work. I don't think you'd be able to include javy-cli as a dependency, because it's a binary, not a library.

Generally (and assuming I'm understanding your use-case correctly) I think we should be able to do a bit better, such that instead of having to spawn a process from your application, you should be able to add a a library dependency that allows building a Wasm module from a JavaScript source. This shouldn't be too hard to accomplish if we start by extracting the code generation pieces used by the cli and publish those as a separate crate (e.g., javy-codegen) to crates.io, then I'm imagining that you'd be able to include that crate in your application like:

[dependencies]
javy-codegen = 1

Note that even though the refactoring to extract this code might be trivial, some open questions still stand, like for example:

• Handling the dependency between the javy-codegen and the Wasm module produced by javy and required by the code generation process.
• Related to the previous point, perhaps this use-case could leverage the most recent work around plugins, in such a way that instead of hardcoding a dependency between javy-codegen and a Wasm module, the Wasm module could be be injected as a dependency, which would probably make all this process easier and the API more flexible.

I think some exploration is needed around those areas to have a better handle of the pros/cons.