The current Rust templates generate a set of separate workspaces:
- app
|- comp1
| |- Cargo.toml
|- comp2
|- Cargo.toml
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:
- app
|- Cargo.toml // New! Exciting!
|- comp1
| |- Cargo.toml
|- comp2
|- Cargo.toml
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>.wasmfile istarget/wasm32-wasi/releaserather than<name>/target/wasm32-wasi/releaseworkdirwatchpaths need to include the directory (unless we keepworkdirbut somehow kerjigger its semantics)Cargo.toml'sworkspace.membersThere is also some structural stuff:
Cargo.toml- we can do this as thenewpart of thenew-addcyclesrc/lib.rsbecause otherwiserust-analysergets 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.tomlto update theworkspace.membersarray. 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.