then app developers could open the top-level directory and work on all components in their application in a single IDE, and would benefit from shared compilation of dependencies (once a dependency had been compiled for one package in the workspace, it would not need to be recompiled for others). This is a non-trivial speedup for all the Wasm shenanigans drawn in by the Spin SDK!
This would involve some changes to the Rust template:
Build command is cargo build --release --target wasm32-wasi -p <name>
Directory for the .wasm file is target/wasm32-wasi/release rather than <name>/target/wasm32-wasi/release
No workdir
So watch paths need to include the directory (unless we keep workdir but somehow kerjigger its semantics)
Aaaaand... we need to add each project to the top-level Cargo.toml's workspace.members
There is also some structural stuff:
We now also need to create a single top-level Cargo.toml - we can do this as the new part of the new-add cycle
As far as I can tell, we need a dummy top-level src/lib.rs because otherwise rust-analyser gets mad because it wants to run cargo check, and that fails if the top-level Cargo.toml doesn't have any code associated with it. I don't know if there's an option to suppress this.
The main challenge with this is editing the existing Cargo.toml to update the workspace.members array. The existing template system should be able to handle the rest, but it can't do that. It's probably not difficult but it's a very Rust-specific feature and I would really like to start getting that kind of stuff out of the template system and into "smarter" templates. Oh well.
Anyway this feels like it makes for more pleasant edit and build experiences for multi-component Rust projects.
The current Rust templates generate a set of separate workspaces:
with separate build commands for each.
This means each component gets a separate IDE experience, separate compilation, etc.
If we also had a workspace at the top level, with the components as workspace members:
then app developers could open the top-level directory and work on all components in their application in a single IDE, and would benefit from shared compilation of dependencies (once a dependency had been compiled for one package in the workspace, it would not need to be recompiled for others). This is a non-trivial speedup for all the Wasm shenanigans drawn in by the Spin SDK!
This would involve some changes to the Rust template:
cargo build --release --target wasm32-wasi -p <name>
.wasm
file istarget/wasm32-wasi/release
rather than<name>/target/wasm32-wasi/release
workdir
watch
paths need to include the directory (unless we keepworkdir
but somehow kerjigger its semantics)Cargo.toml
'sworkspace.members
There is also some structural stuff:
Cargo.toml
- we can do this as thenew
part of thenew-add
cyclesrc/lib.rs
because otherwiserust-analyser
gets mad because it wants to runcargo check
, and that fails if the top-level Cargo.toml doesn't have any code associated with it. I don't know if there's an option to suppress this.The main challenge with this is editing the existing
Cargo.toml
to update theworkspace.members
array. The existing template system should be able to handle the rest, but it can't do that. It's probably not difficult but it's a very Rust-specific feature and I would really like to start getting that kind of stuff out of the template system and into "smarter" templates. Oh well.Anyway this feels like it makes for more pleasant edit and build experiences for multi-component Rust projects.