3.8 KiB
Utilisation de ksp-app-config-desk
État actuel
Le gabarit Rust/Tauri et le frontend Vite/TypeScript/SCSS sont présents. Le backend initialise désormais Config, le runtime Logging et AppState; les panneaux métier Config restent volontairement absents à ce stade.
La fenêtre splash est la fenêtre visible au démarrage. La fenêtre main est déjà construite et bundlée, mais son lifecycle d'affichage est finalisé dans la tranche splash/shell dédiée afin de ne pas introduire une temporisation codée en dur.
Première installation des dépendances frontend
Depuis :
crates/ksp-app-config-desk
installer les dépendances déclarées avec la commande de gestion prévue par le projet :
npm i -D
cd ../../
npm i -D sans nom de package installe les dépendances déclarées du package ; la classification dependencies / devDependencies reste celle de package.json. Les lockfiles frontend restent ignorés et ne sont pas versionnés. Après cette installation, les commandes Cargo/Tauri sont exécutées depuis la racine du workspace.
Développement normal
Le frontend n'est pas lancé directement avec npm. KSP est un workspace Rust multi-app : depuis la racine du workspace, la configuration Tauri de l'application doit être sélectionnée explicitement :
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json
Tauri exécute alors le hook :
npm run dev
Vite écoute strictement sur :
HTTP : 1430
WS : 1431
Si le port HTTP est déjà occupé, le démarrage doit échouer au lieu de sélectionner silencieusement un autre port.
Build frontend
Le build de l'application passe également par Tauri. Depuis la racine du workspace :
cargo tauri build -c crates/ksp-app-config-desk/tauri.conf.json
beforeBuildCommand déclenche :
npm run build
Vite construit les pages main.html et splash.html vers :
../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
Cette destination est résolue depuis la racine de la crate dans vite.config.ts et correspond au frontendDist de tauri.conf.json.
Tracing desktop
tauri-plugin-tracing est enregistré côté Rust et la capability contient tracing:default. Le package frontend associé est installé avec le gabarit.
Cette tranche n'utilise pas encore le bridge JavaScript pour émettre les logs KSP applicatifs : frontend_log.ts, les targets KSP whitelistés et la commande emit_frontend_log sont introduits dans la tranche dédiée après initialisation de ksp-logging-lib.
Bindings TS-RS
Le layout cible est :
frontend/ts/bindings/ksp_app_config_desk/...
Les bindings sont générés au premier DTO Tauri réel ; aucune structure factice n'est ajoutée uniquement pour créer le répertoire.
Bootstrap backend
Les arguments --cfgpath, --schemapath et --filemap=... sont transmis tels quels à ksp-config-lib. Le profil Logging initial est le default_profile de std.logging.json.
Si cette configuration ne peut pas être utilisée, l'application doit rester démarrable pour permettre sa réparation : elle utilise alors un fallback Logging console/stderr en mémoire. Le fallback n'écrit aucun fichier de configuration et n'écrase aucune valeur utilisateur.
La commande Tauri get_app_snapshot expose un état sûr du bootstrap. Ses types TypeScript sont générés par cargo test -p ksp-app-config-desk sous frontend/ts/bindings/.
Asset font du splash
La police bot3 de référence est DOS_Amazigh.ttf. Vérifier l'asset local contre l'empreinte documentée dans frontend/fonts/README.md ; frontend/sass/splash.scss l'applique déjà au titre du splash. La tranche pre.008 reste consacrée au lifecycle et à la finition visuelle.