Suggestion: WebAssembly Plugins

[jameschensmith]

I stumbled across this series of blog posts on Rust plugin architecture recently, and I thought I would bring it up here since it's relevant to the proof-of-concept. I personally thought the WebAssembly (WASM) method was an interesting approach. In fact, that's actually the approach taken by dprint.

Looking forward to a more modular starship prompt! 🚀

[matchai]

Thank you for sharing, James! WASM was on my radar though I have to admit I don't know a whole lot about it.
As much as I value the appeal of making it open to other languages that can output WASM, it would be nice to maintain some degree of consistency between starship plugin designs. By making Rust the supported language for plugins, we can maintain a degree of performance and safety across the "ecosystem", and build tools and practices for easy plugin authoring.
I'll try to get around to reading the blog posts you linked to. 😄

[mainrs]

@jameschensmith I have some rudimentary prompt that uses WASM plugins at its core but is written in Rust. It was my attempt at making spaceship in Rust. matchai beat me to it :) If I come to have time to clean it up I can share it with you :)

Jokes aside, I wanted to chime in to call attention to plugins that would require to run native code. For example the battery plugin or the hostname plugin. Both rely on the interaction with the OS and aren't really pure by means of having some input file they process to get a corresponding output.

This can be circumvented to some degree by using WASI and allowing plugins read-access to a directory or specific file. That way most of the language modules would work.

Something to keep in mind is that the responsiveness of prompts is important. Since starship can't integrate that easily into shells like prompt written in the corresponding shell language (fish, zsh etc.), it doesn't offer advanced features like asynchronous prompt rendering afaik. This makes performance an important factor, since the prompt runs synchronous and everything that takes too much time gets noticed by the user. And IPC between the binary and the WASM plugins is sadly overhead that gets noticed on slower machines. It depends on how much gets pushed through IPC though, but the most overhead comes from setting up the IPC connection and not the data that is pushed through it.

[jameschensmith]

Perhaps this can be revisited, making use of Extism.