[bug] Top Level Cargo Workspace Breaks Tauri Info

[kdumontnu]

Describe the bug

I'm working on setting up Tauri as a front-end for my Rust library, with a top-level Cargo.toml file that looks like the following:

[workspace]
members = [
  "src-tauri",
  
  # core
  "core/my-library"
]

When I run cargo update, it puts Cargo.lock in the top (root) directory. Then, running tauri info shows "(no lockfile)", or older versions of my dependencies if I already have a lockfile in ./src-tauri/.

Reproduction

1. Create a new tauri project
2. Add a Cargo.toml file at the root directory with

[workspace]
members = [
  "src-tauri",
]

3. Run tauri info and you will see (no lockfile) for tauri deps.

Expected behavior

I expect it to default first to use the cargo lock file at the top level (same as cargo).

Platform and versions

`$ npm run tauri info`


> tauri-test-app@0.1.0 tauri
> tauri "info"


Environment
  › OS: Mac OS 12.3.1 X64
  › Node.js: 18.2.0
  › npm: 8.9.0
  › pnpm: 6.11.0
  › yarn: 1.22.15
  › rustup: 1.24.3
  › rustc: 1.62.0-beta.2
  › cargo: 1.62.0-beta.2
  › Rust toolchain: beta-aarch64-apple-darwin 

Packages
  › @tauri-apps/cli [NPM]: 1.0.0-rc.13
  › @tauri-apps/api [NPM]: 1.0.0-rc.6
  › tauri [RUST]: 1.0.0-rc.14 (no lockfile),
  › tauri-build [RUST]: no manifest (no lockfile),
  › tao [RUST]: no manifest (no lockfile),
  › wry [RUST]: no manifest (no lockfile),

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../dist
  › devPath: http://localhost:3000/
  › framework: Vue.js

App directory structure
  ├─ core
  ├─ test
  ├─ dist
  ├─ target
  ├─ node_modules
  ├─ public
  ├─ src-tauri
  ├─ .git
  ├─ .vscode
  └─ src

Stack trace

No response

Additional context

I'm pretty new to Tauri and Rust, so if this is not the "correct" way of structuring my project I can close this, but it was very confusing to me initially that I was seeing outdated versions of tauri in my tauri info when using cargo workspaces.

I could place the library directory (core/) as a sub-directory in ./src-tauri and move my workspace into that directory as well, but that seems counter to what I'm trying to build, where tauri is an optional front-end to this library, and the main component of my repo is in core.

[metkm]

I would like to see how we should use tauri with a workspace setup on the docs.

[FabianLars]

so if this is not the "correct" way of structuring my project I can close this

While it's not the standard/default layout, using cargo (virtual) workspaces is totally fine. I do that all the time too. And yes tauri info can't handle it, and we knew that already, but it wasn't high enough in priority to delay v1 for it.

[evbo]

@sibyl666 I agree about docs but honestly I just followed the docs here and no real issues getting workspaces running in tauri:
https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
(where src-tauri is just another workspace essentially)

the only caveat
I don't think cargo tauri build tells you if your other workspaces are failing to build, it will just tell you their crates were not resolved (or maybe I missed where it told me that). So just to be safe you can run plain old cargo build for a single workspace, which should compile in under a second in the simplest case. Then cd to the root project to run a full build.

and a gotcha
Carefully notice in the linked Rust docs how the workspace uses lib.rs instead of main.rs. This is not just a cleaner name - it is a convention you must adhere to in order for your src-tauri/src/main.rs to be able to import from your other workspace!

note in passing
For anyone not currently using workspaces who's doing TDD you're seriously going to want to know about this little secret; they enable lightening fast unit tests by not having to build the entire Tauri app + whatever mountains of code you may have each time you want to just run a simple unit test. Break your code into manageable workspaces and unit test them individually. Say hello to speed!

Definitely recommend using workspaces for any tauri project and maybe tauri docs should encourage this?