Dioxus App with Workspaces

[r0wdiggity]

Problem

I am using the workspaces setup from the CLI. Instead of having all the dependencies in the workspace Cargo.toml, I have the server dependencies in the server workspace's Cargo.toml, the web dependencies in the web's Cargo.toml and the UI dependencies in the ui's Cargo.toml. I don't have the optional crates with dependencies true, as I expected the seperation of the workspaces to handle the workspace specific dependencies. I am getting a compilation error on dx serve however.

If this is not the expected behavior, are there any workspace examples out there? The docs all refer to the Cargo.toml singular, so its unclear in the workspace setup which Cargo.toml gets what piece.

Steps To Reproduce

Steps to reproduce the behavior:

setup a new project with the CLI

• Workspace
• fullstack: true
• router: true

add tokio and axum as dependencies in the server workspace Cargo.toml

tokio = { version = "1", features = ["full"] }
axum = "0.7.9"

dx serve from web

Expected behavior

I would expect the dependencies in the server workspace to only compile with the server, so the app should build normally.

Environment:

• Dioxus version: 0.6.1
• Rust version: 1.84.0 (stable)
• OS info: MacOS
• App platform: web

Questionnaire

I'm interested in fixing this myself but don't know where to start

[r0wdiggity]

I got the app working in a single build, but still cant get it working with workspaces

[ealmloff]

add tokio and axum as dependencies in the server workspace Cargo.toml

The server crate in the workspace template is built on both the server and the client so that the server functions are available to the client. You need to make tokio and axum optional and enable them only when the server feature on the server crate is enabled as documented here. The server feature needs to be forwarded to the entry point web/desktop/mobile crates as well.

Here is a heavily documented version of the workspace template. There is a PR open adding a more limited form of that documentation to what the CLI genreates here: https://github.com/DioxusLabs/dioxus-template/pull/54

This comment in the Cargo.toml of the server crate might have been helpful:

[features]
# The server feature should be enabled when building the server
# Any dependencies that are only required for the server build should be optional and only enabled in the server feature
server = []

[Deedasmi]

Specifically, what I've realized, is that the UI crate depends on Server which will cause compilation to fail if server/Cargo.toml is not configured correctly

[nickdoherty]

When using workspaces and server only dependencies this appears to be broken.

I've spent a few days trying different options, checking out & trying @ealmloff template solution, but any time you include the server only dependency it breaks.

If this is indeed working and it's a configuration issue could we please get an example?

If not, if this issue could be investigated soon, that would be ideal.

[jkelleyrtp]

We recently added support for separate server and client packages. You could also use different entrypoints on the same package (--bin) or custom features (--features)

dx serve \
    @client --package web \ 
    @server --package server

I don't think this fixes the exact bug in this issue (not sure I understand it completely) but this might be helpful for anyone running into this issue.

[acheronte]

This issue also applies to transitive dependencies. I don't use tokio and mio directly but they were the cause of the root Cargo.toml blowing up and build failing. Using cargo tree I found that

  ├── dioxus v0.7.1
│   │   ├── dioxus-asset-resolver v0.7.1
│   │   │   ├── tokio v1.48.0
│   │   │   │   ├── bytes v1.10.1 (*)
│   │   │   │   ├── libc v0.2.177
│   │   │   │   ├── mio v1.1.0

dioxus-asset-resolver was pulling tokio and mio. A bunch of other server-only crates were compounding the issue by also depending on tokio and mio. So I ended up refactoring frontend/UI and backend/server code into their own crates and their respective Cargo.toml files.

The drawback of doing that is that I can't use server functions, from the UI, if the server function requires some data that is only available in the server, i.e. I/O operations (think of an .env file).