App de Bureau

App de Bureau

Branche : desktop-app

Wrapper Electron autour de l'app web : même interface, même code de conversion (public/), sans rien changer — juste une fenêtre native au lieu du navigateur. Quatre modes (Convertisseur / Compresseur / Inspecteur / Comparateur, y compris la catégorie Sous-titres et la compression audio), thème clair/sombre automatique, historique local et notifications natives inclus, voir App Web pour le détail — le code est partagé, donc identique dans les deux apps.

Installation / build local

npm install
npm start          # lancer l'app
npm run dist        # construire un installateur pour l'OS courant

Génère un .dmg sur macOS, un .exe (NSIS) sur Windows, un .AppImage sur Linux.

Téléchargements

Dernière release — voir Releases et versioning ci-dessous pour le détail du schéma de publication.

⚠️ Les builds ne sont pas signés (pas de certificat) : Windows SmartScreen et macOS Gatekeeper afficheront un avertissement au premier lancement. Voir FAQ.

Installateurs personnalisés

• Windows (NSIS) — assistant classique (oneClick: false) avec choix du dossier d'installation, licence MIT à accepter, bannière (150×57) et barre latérale (164×314) aux couleurs d'Anyform.
  • build/license.txt — texte de licence
  • build/installer-header.bmp / build/installer-sidebar.bmp — visuels (BMP 24-bit, générés par rendu HTML→PNG via Chromium headless puis encodage BMP)
• macOS (DMG) — fenêtre d'installation avec fond personnalisé (build/dmg-background.png, 540×380) illustrant le glisser-déposer vers /Applications.
• Linux (AppImage) — pas d'assistant graphique ; personnalisation limitée à l'icône et aux métadonnées (build.linux dans package.json).

Builds automatiques (GitHub Actions)

Le workflow .github/workflows/build-desktop.yml a trois jobs séquentiels :

bump  →  build (matrice Windows/macOS/Linux)  →  release

• bump incrémente le patch de package.json et pousse ce commit avant que build ne démarre — les jobs build repartent explicitement de la HEAD de la branche (ref: desktop-app, pas du commit qui a déclenché le run) pour embarquer ce nouveau numéro de version dans les installateurs générés.
• release lit la version (même principe : ref: desktop-app) et publie une release GitHub taguée vX.Y.Z.

Ce design en jobs dépendants évite une race condition : sans lui, le job build pourrait démarrer avant que le numéro de version soit incrémenté, et produire des installateurs avec l'ancien numéro.

Releases et versioning

Chaque build publie sa propre release, taguée avec le numéro de version (v1.0.7, v1.0.8...) — les fichiers portent eux aussi la version dans leur nom (Anyform-1.0.7-win-x64.exe, etc.), la plus récente étant marquée Latest.

Seules les 10 releases les plus récentes sont conservées : le workflow supprime automatiquement les plus anciennes à la fin de chaque publication (gh release list / gh release delete).

Historique : la première version de ce pipeline publiait vers une release unique desktop-latest, mise à jour à chaque build. Problème : les noms de fichiers versionnés (générés par electron-builder) ne correspondaient jamais entre deux builds, donc les anciens fichiers s'accumulaient au lieu d'être remplacés. Remplacé par le schéma actuel (une release par version).

Les fichiers sont aussi disponibles 30 jours dans les Artifacts du run pour du débogage rapide.

Mise à jour automatique

L'app vérifie au démarrage (uniquement sur un build packagé, jamais via npm start — pas d'app-update.yml ni de release à comparer en dev) si une nouvelle release GitHub est disponible, via electron-updater (main.js). Si oui, elle la télécharge en arrière-plan puis propose de redémarrer pour l'installer — rien d'automatique sans confirmation de l'utilisateur.

Ça s'appuie sur les fichiers latest.yml / latest-mac.yml / latest-linux.yml, générés par electron-builder à chaque build grâce à la config build.publish dans package.json (provider GitHub) — même avec --publish never dans le script dist, ces fichiers de métadonnées sont écrits localement dès qu'une config publish existe. Ils sont uploadés en CI aux côtés des installateurs (dist/latest*.yml ajouté aux artefacts et à la release).

Testé en conditions réelles : une version installée détecte, télécharge et propose d'installer une version plus récente publiée ensuite.

Cache CI : testé, pas gardé

Un cache npm + Electron/electron-builder a été ajouté puis retiré après mesure : sur 3 runs (référence, cache-miss, cache-hit), le cache-hit était plus lent que la référence sur Windows (98s vs 71s pour le job complet), et neutre sur macOS/Linux. Les runners GitHub ont déjà un réseau rapide vers npm/le CDN Electron — le téléchargement n'était jamais le goulot d'étranglement, et le coût de restauration/sauvegarde du cache (~120 Mo par OS) dépasse le gain potentiel. Conclusion : pas de cache sur ce workflow.

Structure du code

• main.js / preload.js — process principal Electron
• build/icon.png — icône de l'application
• build/license.txt, build/installer-*.bmp, build/dmg-background.png — ressources d'installateur (voir plus haut)
• public/ — même code que l'app web, y compris compress.js, subtitles.js, history.js, inspect.js et compare.js (voir App Web)