spinframework / spinframework/spin

Templates: support Cargo workspaces

Open
#2,490 1 comment 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
6.5k
Forks
310
Avg merge
1d 20h
Merged PRs (30d)
24

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Rust template and the new-add cycle, then inspect how Cargo.toml, src/lib.rs, build commands, workdir, and watch paths are generated. Add top-level workspace support and verify that each component is listed as a workspace member, builds to target/wasm32-wasi/release, and works with the described IDE and watch behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, wasm
Domain
build-system, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.