Clarify that `just build` is the production no-bundle launcher build, while fixture builds are explicit. Document package-directory generation, the `LANSPREAD_GAMES_DIR` and `--set GAMES_DIR` default-run forms, the metadata cache behavior, and the force-refresh override so the catalogue workflow is usable without consulting the recipe implementation. Test Plan: - `prettier --check --prose-wrap always --print-width 80 README.md CLAUDE.md` -- passed - `just --fmt --check` -- passed - `git diff --cached --check` -- passed
66 lines
2.7 KiB
Markdown
66 lines
2.7 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 fixture GUI, or real data when `LANSPREAD_GAMES_DIR` is
|
|
set.
|
|
- `just build` — validate production authority and build the launcher without
|
|
bundling.
|
|
- `just build-production PACKAGES_DIR` — generate/reuse production authority and
|
|
build.
|
|
- `just run-fixture` / `just build-fixture` — use the test-only catalogue
|
|
explicitly.
|
|
- `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`.
|