Contributing
Contributions are welcome – bug fixes, features, translations and docs. This page explains how the project is organized and what a pull request needs.
Before you start
- Look at the issue tracker and the roadmap. Maybe someone is already on it.
- For bigger changes, open an issue or ask on Discord first, so the work fits the plan.
- Set up your environment as described in Build from source.
Branches and pull requests
| Branch | Contains |
|---|---|
main | The launcher (app/, src-tauri/) and the TRS Client (client-mod/). Releases are tagged v… from here. |
website | The website and the TRS API (api/). |
Create a branch
Fork the repository and create a branch from main – or from website if you change the website or the API.
Make your change
Keep a pull request to one topic. Write commit messages in English.
Run the checks
Run the checks below for the part you changed. For the launcher, the CI runs them on every pull request as well. Fix everything before you ask for a review.
Open the pull request
Target the branch you started from. Describe what changes for players and how you tested it.
Checks
pnpm typecheck
pnpm test
pnpm generate
cd src-tauri
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace
cd client-mod
./gradlew build
cd api
pnpm typecheck && pnpm lint && pnpm test
Clippy warnings count as errors. The launcher CI runs on Windows and Linux.
How the code is built
The launcher follows a few rules. Please keep to them.
- Logic lives in
trs-core(src-tauri/crates/core). The Tauri layer stays thin, and the core checks every input itself. - The webview gets no file system, network or shell permissions. Everything goes through dedicated commands, under a strict Content Security Policy.
- Only a stable error code and a readable message reach the interface. Paths, URLs and error chains go to the log.
Errors in the core are created with a translation code, for example
msg!("settings.memoryRange", "…", min = 512, max = 4096); the interface shows the text fromerrors.<code>. - No hard-coded text in the interface. Every text is a key in the language files (see Translating). Keys are typed, so typos fail the type check.
For the TRS Client:
- Shared logic goes into
client-mod/commonand stays Java 8, because it is compiled into every version. - Version-specific code is kept in a few places and written with Stonecutter comments (see
client-mod/README.md). - Fair play: no reach or hitbox changes, no auto-clicking, and the minimap only shows loaded chunks, without cave view.
Tests
Add tests for new logic:
- Frontend: Vitest files in
tests/. - Rust: unit tests next to the code; run with
cargo test --workspace. - Crash helper: a new rule needs a function in
crash/rules.rs, a sample log incrash/fixtures/, a test and the textscrashHelper.findings.<kind>.<variant>in the language files. - TRS Client: unit tests in
client-mod/common, for exampleI18nTest.
Changelog
Every change that players notice gets an entry in CHANGELOG.md, in English and German. Collect it under
## Unreleased:
## Unreleased
### English
- **Log search.** The log view now finds text in folded stack traces too.
### Deutsch
- **Log-Suche.** Die Log-Ansicht findet Text jetzt auch in eingeklappten Stacktraces.
- Both languages have the same points.
- Write for players, not for developers: what changes for them, in plain words, without file or function names.
- The release build copies the section into the GitHub release and the "What's new" dialog the launcher shows after an update. It fails if a language is missing.
License
The TRS Launcher and the TRS Client are licensed under the GNU General Public License v3.0 (GPL-3.0-only). By contributing, you agree that your contribution is released under the same license.
.env files. The CurseForge key and the signing keys are only read from the
environment or from files outside the repository.