Files
RAPPORT-WEBSITE/content/docs/entwicklung.md
T
2026-05-26 11:52:03 +02:00

5.2 KiB

title, linkTitle, weight, toc
title linkTitle weight toc
Entwicklung & Build Entwicklung 7 true

Aus dem Quellcode kompilieren, beitragen, eigenes Release erzeugen.

Voraussetzungen

Tool Version
Node.js ≥ 20 (für Vite 8)
npm ≥ 10
Rust toolchain ≥ 1.77.2 (via rustup)
Plattform-Tools siehe Tauri Prerequisites

Plattform-spezifisch:

  • macOS: Xcode Command Line Tools (xcode-select --install)
  • Windows: Microsoft C++ Build Tools + WebView2
  • Linux: webkit2gtk-4.1, librsvg2-dev, libayatana-appindicator3-dev, build-essential

Setup

git clone https://git.kgva.ch/karim/RAPPORT.git
cd RAPPORT/APP
npm install

Entwicklung

Web-Modus (HMR, schnellster Loop)

npm run dev          # http://localhost:3000
  • Hot-Module-Replacement
  • Schnellster Iteration-Loop für UI-Arbeit
  • Datenpersistierung: Browser-localStorage

Native Window (Tauri-Fenster mit Desktop-Integration)

npx tauri dev
  • Echtes Tauri-Fenster
  • System-Tray, Updater, native APIs verfügbar
  • Erster Start dauert lange (Rust-Compile)

Architektur in einem Absatz

RAPPORT ist eine monolithische SPA: ein React-Root in App.jsx hält den gesamten App-State in einem useState({...}), persistiert ihn synchron in localStorage unter studio_data_v1, und übergibt ihn als Props an lazy-geladene Views. Kein Routing-Framework, kein State-Library, kein TypeScript, kein CSS-Framework. Der Rust-Teil ist 109 Zeilen und macht nur drei Dinge: System-Tray, Window-Hide-on-Close, Plugin-Registrierung (Updater, Process, Log). Keine #[tauri::command] — Frontend ↔ Backend kommuniziert nur über das Event rapport:navigate (Tray → Frontend).

Detaillierte Karte: ARCHITECTURE.md.

Verzeichnis-Karte

APP/
├── src/                      React 19 (kein TS, nur .jsx)
│   ├── App.jsx               Root: State, Navigation, Sidebar, Modals
│   ├── constants.js          STORAGE_KEY, NAV_ITEMS, defaultData, SIA-Phasen
│   ├── utils.js              Business-Logik: Kalkulation, QR-Bill, CSV, Lohn
│   ├── storage/adapter.js    LocalStorageAdapter (Phase 1), SupabaseAdapter (Phase 2)
│   ├── storage/migrations.js Schema-Migrationen
│   ├── views/                20 Top-Level-Screens, lazy-geladen
│   ├── components/UI.jsx     StatusBadge, Modal, FormField, …
│   ├── components/Update*    Auto-Update-UI
│   ├── print/                PrintComponents.jsx — alle Druckansichten
│   └── utils/updater.js      @tauri-apps/plugin-updater Wrapper
│
├── supabase/migrations/      Postgres-Schema für Cloud-Variante
│
├── src-tauri/                Rust-Backend (Tauri 2.10.3)
│   ├── src/lib.rs            ~103 Z. — Tray, Window-Events, Plugins
│   ├── tauri.conf.json       Updater-URL, Public-Key, CSP, Bundle-Targets
│   └── capabilities/         Tauri Permissions
│
├── scripts/release.sh        Build + Sign + latest.json erzeugen
├── latest.json               Updater-Manifest
└── deploy/                   Docker-Compose für Web-Modus

Konventionen

  • JavaScript statt TypeScript — bewusste Entscheidung für Solo-Dev-Velocity
  • Inline-Styles statt CSS-Framework
  • kein Routing-Frameworkview-State in App.jsx triggert Komponente
  • JSON-Schema implizit — definiert durch defaultData in constants.js
  • Migrationen als reine Funktionen in storage/migrations.js

Build

Desktop (Tauri DMG)

npm run build         # erst Vite-Build (dist/)
npx tauri build       # dann Tauri-Bundle (DMG)

Output: src-tauri/target/release/bundle/dmg/Rapport_<version>_aarch64.dmg

Web (statisches Bundle)

npm run build         # Output: dist/ (~500 KB)

Für Hosting auf einem Static-Server (z. B. Nginx, Caddy, GitHub Pages). Siehe Web-Modus.

Release-Workflow

# 1 · Version bumpen in package.json + Cargo.toml + tauri.conf.json
./scripts/release.sh 0.7.1

# 2 · Build mit Signatur
TAURI_SIGNING_PRIVATE_KEY=$(cat ~/.tauri/rapport-key) \
TAURI_SIGNING_PRIVATE_KEY_PASSWORD=\
npx tauri build

# 3 · latest.json aktualisieren mit neuer Signatur

# 4 · DMG + latest.json auf Gitea Releases hochladen

Beitragen

Issues & Pull Requests sind willkommen. Wertvoll sind:

  • Bug-Reports mit Reproduktionsschritten
  • Workflow-Verbesserungen aus dem realen Büroalltag
  • Vorlagen (Briefe, Protokolle, Lieferscheine) für andere Büros
  • Übersetzungen / Internationalisierung (FR, IT)
  • Linux-/Windows-Builds und plattformspezifische Fixes

Vor grösseren Änderungen → Issue zum Diskutieren.

Lizenz

GNU AGPL-3.0-or-later — eigene Builds erlaubt, Modifikationen müssen unter derselben Lizenz veröffentlicht werden, wenn die Software als Service angeboten wird.