ddidderr
5df82aa4f3
The launcher was mixing lifecycle event handlers with the games-list snapshot when deciding the card status. That left multiple writers for the same install_status field and made event ordering visible in React. Make games-list-updated active_operations the authoritative source for busy status. Lifecycle events no longer mutate the card status; they only keep their non-status side effects such as rescans and error messages. The only remaining optimistic status is CheckingPeers before the backend emits its next snapshot. Add a frontend reducer test that proves an install stays in Installing while an active install snapshot exists, then settles to Installed only after the active operation clears with installed local state. Test Plan: - git diff --check - just fmt - just frontend-test - just build Refs: local install/download status snapshot cleanup
48 lines
2.4 KiB
Markdown
48 lines
2.4 KiB
Markdown
# lanspread
|
|
|
|
Peer-to-peer game library sharing for LAN parties. Peers discover each other on the local network via mDNS, exchange library metadata over QUIC, and let users browse and download games from each other. Ships as a Tauri desktop app.
|
|
|
|
## Workspace layout
|
|
|
|
Cargo workspace under `crates/`:
|
|
|
|
- `lanspread-peer` — core peer: networking, library, downloads, services. Start here for behavior changes. See `crates/lanspread-peer/ARCHITECTURE.md`.
|
|
- `lanspread-proto` — wire protocol types shared across peers.
|
|
- `lanspread-mdns` — mDNS-SD discovery wrapper.
|
|
- `lanspread-db` — database/schema types (sqlx + sqlite).
|
|
- `lanspread-compat` — compatibility/migration glue between db and other crates.
|
|
- `lanspread-utils` — small shared helpers.
|
|
- `lanspread-peer-cli` — JSONL peer harness for scripted and containerized tests.
|
|
- `lanspread-tauri-deno-ts/` — frontend (Vite + Deno + TS in `src/`) and Tauri shell (`src-tauri/`). This is the GUI client.
|
|
|
|
Top-level `Cargo.toml` pins workspace dependency versions; per-crate `Cargo.toml`s set lints (pedantic clippy, `unsafe_code = forbid` on most).
|
|
|
|
## Commands (justfile)
|
|
|
|
Never use normal cargo ... commands, use the just ... commands instead.
|
|
|
|
- `just run` — run the GUI in dev mode.
|
|
- `just build` — build the GUI without bundling (also dev mode).
|
|
- `just fmt` — format the workspace.
|
|
- `just clippy` — lint the workspace.
|
|
- `just test` — run the workspace unit tests.
|
|
- `just frontend-test` — run frontend reducer/unit tests.
|
|
- `just fix` — auto-apply cargo/clippy fixes, then format.
|
|
- `just clean` — wipe the build cache.
|
|
- `just peer-cli-build` — build the scripted peer harness.
|
|
- `just peer-cli-image` — build the peer harness Docker image.
|
|
- `just peer-cli-run NAME` — run one named harness container with persistent state under `.lanspread-peer-cli/NAME/`.
|
|
|
|
## Protocol policy
|
|
|
|
There is only one wire version — the current one. No legacy peers, no compatibility shims, no fallback paths for older builds. Anyone who wants to interop must run the current build; everyone else is out. Do not add backward-compat code, `#[serde(other)]` escape hatches, or "what if an old peer sends X" defenses.
|
|
|
|
## Manual CLI testing (docker container)
|
|
|
|
Start `just peer-cli-alpha`, `just peer-cli-bravo` and `just peer-cli-charlie` each in its own terminal. You then have 3 peers that you can interact with via stdin/stdout (JSONL).
|
|
Use this setup to manually test peer functionality.
|
|
|
|
## General info
|
|
|
|
See `README.md`.
|