- workflow: un seul job build Windows (Wine) + Linux puis publie tout - publish-gitea.mjs: publie latest-linux.yml, AppImage, deb - package.json: homepage (requis pour le build deb) + scripts build:all/publish - publie toujours les 2 plateformes (le script efface tous les assets avant upload) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
7.4 KiB
OFLauncher
Launcher Minecraft custom pour jouer à All The Mods 10 (Minecraft 1.21.1 / NeoForge / Java 21) entre potes, avec mise à jour incrémentale du modpack : quand tu changes le pack, les joueurs ne re-téléchargent que ce qui a changé.
- UI : Electron + React + TypeScript
- Auth Microsoft :
prismarine-auth(cache + refresh automatique) - Runtime MC / NeoForge :
@xmcl/core+@xmcl/installer - Java 21 : JRE Temurin (Adoptium) téléchargé et géré automatiquement
- Sync du modpack :
packwiz-installer(delta par hash, conforme CurseForge)
1. Développement
npm install # une fois
npm run dev # lance le launcher en mode dev (hot reload)
npm run typecheck # vérifie les types main + renderer
npm run build # build de production (out/)
2. Configuration (la seule chose à éditer dans le code)
Tout est dans src/shared/config.ts :
| Champ | À mettre |
|---|---|
packTomlUrl |
URL publique de ton pack.toml packwiz (voir §4) |
azureClientId |
Client ID de ton app Azure (voir §3). Laisse CHANGE_ME pour tester |
serverAddress |
(optionnel) ip:port du serveur pour rejoindre en un clic |
Les versions Minecraft et NeoForge ne sont PAS dans le code : elles viennent
du pack.toml. Pour changer de version, tu mets à jour le pack, pas le launcher.
3. Auth Microsoft
Par défaut (azureClientId = "CHANGE_ME"), le launcher utilise le flow live
qui fonctionne tout de suite pour tester, sans app Azure.
Pour la version « propre » d'un launcher tiers (recommandé en prod) :
- Crée une app sur Azure Portal → App registrations
(comptes personnels / consumers), avec le scope
XboxLive.signin. - Demande l'accès à l'API Minecraft via le formulaire Microsoft — cette approbation peut prendre du temps, fais-le tôt. Réf : https://learn.microsoft.com/answers/questions/5768276/
- Mets le Client ID dans
config.azureClientId. Le launcher bascule alors automatiquement sur le flowmsal.
Le login se fait en device code : le launcher ouvre la page Microsoft et affiche un code à saisir. Le token est mis en cache (pas de re-login ensuite).
4. Créer et héberger le modpack (côté admin = toi)
Le modpack est géré avec packwiz (CLI).
# 1. Récupère une clé API CurseForge (https://console.curseforge.com) -> CF_API_KEY
# 2. Crée le dépôt packwiz à partir d'ATM10 (depuis le .zip CurseForge d'ATM10) :
packwiz init # renseigne MC 1.21.1 + NeoForge
packwiz cf import All-the-Mods-10-x.y.z.zip # importe les mods + configs
# 3. À chaque modif du pack :
packwiz cf add <mod> # ajouter un mod CurseForge
packwiz update --all # mettre à jour les mods
packwiz remove <mod> # retirer un mod
packwiz refresh # régénère index.toml (le manifeste hashé)
git add -A && git commit -m "update pack" && git push
Hébergement (à décider) : le plus simple est GitHub.
- Pousse le dossier packwiz dans un repo (ex.
OFModpack). packTomlUrl= lien raw verspack.toml, ex.https://raw.githubusercontent.com/<user>/OFModpack/main/pack.toml.- (ou GitHub Pages pour une URL plus propre.)
À chaque lancement, le launcher relit pack.toml/index.toml et ne télécharge
que les fichiers dont le hash a changé ; les fichiers retirés du pack sont
supprimés de l'instance du joueur.
Mods CurseForge non-redistribuables : la grande majorité d'ATM10 se télécharge automatiquement. Pour les rares mods qui interdisent la redistribution, packwiz les signalera ; au besoin tu peux les héberger toi-même (si la licence le permet) via un bloc
[download]dans le.pw.toml.
5. Build des binaires
npm run build:win # installeur Windows (.exe NSIS) -> dist/
npm run build:linux # AppImage + .deb -> dist/
Auto-update du launcher (via Gitea)
Le launcher se met à jour tout seul : au démarrage il lit latest.yml à l'URL
configurée dans electron-builder.yml (publish.url), télécharge la nouvelle
version en fond et propose un bouton « Redémarrer pour installer ».
Les artefacts sont hébergés sur une release Gitea à tag fixe latest
(provider generic d'electron-updater — il n'y a pas de provider Gitea natif).
À chaque publication, les assets de cette release sont écrasés.
Pré-requis côté Gitea (une fois) :
- un repo launcher, ex.
gitea.ldpt.fr/zertus/OFLauncher; - un token d'accès avec le scope
write:repository.
Publier une nouvelle version :
npm version patch # bump 0.1.0 -> 0.1.1 (la version EST la source de vérité)
export GITEA_TOKEN=xxxxx # token Gitea (scope write:repository)
npm run publish # build Windows + Linux puis upload de tous les artefacts
scripts/publish-gitea.mjs crée la release latest si besoin, supprime tous
les anciens assets puis uploade les nouveaux (Windows + Linux). C'est pourquoi on
build les deux plateformes avant de publier (build:all) : une publication ne
contenant qu'une plateforme effacerait l'autre. URL/owner/repo/tag sont
surchargeables via GITEA_URL / GITEA_OWNER / GITEA_REPO / GITEA_TAG.
Publier via Gitea Actions (CI, déclenchement manuel) — au lieu de builder en
local, tu peux lancer le workflow .gitea/workflows/publish.yml depuis l'onglet
Actions du repo (bouton « Run workflow »). Sur un runner Linux (image
electronuserland/builder), il build l'installeur Windows (NSIS, via Wine) et
les paquets Linux (AppImage + .deb), puis publie le tout sur la release
latest. Optionnellement, l'input bump (patch/minor/major) incrémente la
version et pousse le commit avant le build. Pré-requis : Gitea Actions activé +
un act_runner enregistré (label ubuntu-latest, à adapter) ; un secret repo
RELEASE_TOKEN (scope write:repository) pour publier la release.
Tester le flux en dev :
dev-app-update.yml(déjà présent) pointe sur la même URL ; avec une version distante > version locale, le bandeau de maj apparaît ennpm run dev(l'install réelle ne se fait toutefois qu'en build packagé).
6. Où vivent les fichiers
Sous le dossier userData d'Electron (%APPDATA%/OFLauncher sur Windows,
~/.config/OFLauncher sur Linux) :
minecraft/ runtime géré par @xmcl (versions, libraries, assets) — jamais touché par packwiz
instance/ mods/, config/, saves/ — cible de la sync packwiz
java/ JRE Temurin 21 géré
auth-cache/ tokens Microsoft (refresh auto)
settings.json réglages (RAM, args JVM)
Architecture (code)
src/
├── shared/ config + contrats IPC partagés main/renderer
├── main/
│ ├── index.ts bootstrap Electron + handlers IPC
│ ├── auth.ts login/refresh/logout Microsoft
│ ├── java.ts provisioning Temurin 21
│ ├── install.ts install MC + NeoForge (@xmcl)
│ ├── modpack.ts pack.toml + sync packwiz
│ ├── launch.ts lancement du jeu (@xmcl)
│ ├── play.ts orchestration de la séquence "Jouer"
│ └── ...
├── preload/ pont IPC typé (window.api)
└── renderer/ UI React