Partir du bootstrap et préparer le runtime

Une création d’appli copie le bootstrap de la plateforme dans sa première version. Un pull récupère les fichiers de cette version : il ne remplace pas une ancienne appli par le dernier template. Commencer par dev-workflow pour identifier le workspace et le runtime effectivement servis.

Bootstrap classique

infos.json déclare app-index, les possibilités d’affichage, les formats, les scopes et les ressources. index.html installe son écouteur document.addEventListener('AppliLoaded', …, {once: true}) avant le script SDK, puis charge style.css et script.js. Le code métier utilise alors kapp, les préférences et le textset initialisés. La fin du script ne termine pas l’appli : voir cycle de vie.

Le textset est déclaré par textset: 'textset.js'. preferences.config.js est la source compilée par le HUB ; modules/Model.js aide à composer cette configuration. streamer.md et viewers.md sont des modèles de guides à compléter, déclarés par leurs deux clés *-readme. Un nom de fichier seul ne suffit pas. Les anciens bootstraps peuvent avoir ces clés à null, manquer data.config.json ou installer l’écouteur trop tard : contrôler les fichiers reçus, sans écraser les personnalisations.

Le runtime complet comporte six configurations sous config/ :

Fichier	Forme neutre pour un projet sans cette fonctionnalité
preferences.config.json	{"type":"group","groupItems":{}}
data.config.json	{}
default_triggers.config.json	[]
historics.config.json	[]
player_stats.config.json	[]
trigger_arguments.config.json	[]

Ces formes vides ne remplacent pas les configurations d’une appli existante. data.config.json décrit la configuration historique des données ; sa présence ne constitue pas une sauvegarde de partie ni une migration vers les stockages V2.

Les déclencheurs par défaut sont appliqués à l'installation ou lors d'une réinitialisation explicite par le streamer. Une app doit déclarer PROCESSUS dans cette liste si elle souhaite proposer un démarrage automatique ; [] est également valide. Voir manifeste et compatibilité des déclencheurs.

Projet compilé

Le HUB propose aussi un scaffold TypeScript/Vite sur un workspace éligible. Il refuse les fichiers métier déjà présents ; ce n’est pas un outil de conversion d’une appli existante. Vérifier le template de la version du HUB utilisée : déclarations de guides, formats et six configurations restent à compléter si absentes.

Utiliser son bundler existant et runtime.root, sans créer un second compilateur de configurations. L’exemple compilé complet illustre une entrée Vite, des sources séparées, des guides copiés dans le runtime et les six entrées du compilateur HUB.

L’ordre dépend du build : si celui-ci vide dist, exécuter build → transpile → contrôle du runtime → preview. Un build lancé après transpile peut effacer les JSON. Le watch du HUB observe les configurations ; il ne reconstruit pas automatiquement le JavaScript. Le push prépare les configurations et le manifeste, mais ne remplace pas le build métier.

Dans un module chargé par le bundler, installer l’écouteur puis injecter le SDK : un script SDK placé dans le HTML avant un module différé peut démarrer avant l’inscription du module. Prévoir un état de chargement, un message d’échec et une durée maximale d’attente, sans relancer automatiquement les effets métier. Les scripts locaux et le SDK doivent être chargés une seule fois.

Contrôler ce qui sera servi

Le runtime est autonome : entrée HTML, JS/CSS générés, ressources, guides, manifeste et configurations. Les chemins du manifeste sont relatifs à ce runtime, sans préfixe dist/. Les entrées de configCompiler restent relatives au workspace et leurs noms de base déterminent les fichiers JSON de sortie ; ne pas donner le même nom à deux entrées différentes.

Tester la sortie de build depuis le serveur du HUB, pas seulement le serveur de développement du bundler. Un module qui marche grâce à /src/ ou à node_modules peut manquer dans le ZIP publié. Pour les prérequis fonctionnels, la présentation et les guides : livraison.