Exécuter et déboguer

Gitcito lit votre .vscode/launch.json — celui de la racine et tous ceux qui sont imbriqués, groupés par des séparateurs — et exécute la configuration que vous choisissez dans le terminal intégré.

• Les variables VS Code sont résolues (${workspaceFolder} et consorts).
• Le preLaunchTask d'une configuration s'exécute d'abord.
• Les valeurs ${input:…} sont demandées interactivement avant le lancement (promptString et pickString). Un pickString affiche ses options dans un vrai sélecteur avec la valeur par défaut présélectionnée ; un promptString marqué password est masqué.
• Les tâches isBackground (observateurs, serveurs de développement) s'exécutent détachées : elles ne bloquent donc jamais le lancement.
• Les compounds lancent chaque membre dans sa propre session parallèle, dans un terminal scindé portant le nom du compound — un volet par membre, exactement comme les sessions de débogage de VS Code. Avec stopAll: true, arrêter un membre les arrête tous. Les tâches partagées par plusieurs membres s’exécutent une seule fois, dans leur propre volet, avant le démarrage des membres — une invite de montée de version ne demande qu’une fois, pas une fois par membre. Ce volet se ferme seul en cas de succès et reste ouvert en cas d’échec.
• serverReadyAction est pris en charge : quand la sortie de la session correspond au motif configuré, l’URL annoncée s’ouvre dans votre navigateur (openExternally ; debugWithChrome / debugWithEdge ouvrent aussi le navigateur — Gitcito ne peut pas y attacher de débogueur).

Une barre d'outils flottante vous donne pause / reprise, redémarrage, arrêt, et permet de passer d'une session en cours à l'autre.

Activez-le dans Réglages → Général → Activer launch.json. Le bouton LANCER apparaît à côté des onglets Git / Fichiers.

Un membre d’un compound s’affiche comme compound › membre, et le redémarrer ne redémarre que ce membre. Si la barre recouvre quelque chose dont vous avez besoin, déplacez-la par sa poignée — la position est mémorisée, et un double-clic sur la poignée la recentre.

Ce que Gitcito ne fait délibérément pas : il exécute vos programmes dans de vrais terminaux, mais ce n’est pas un débogueur — pas de points d’arrêt, pas d’inspection de variables, pas de Debug Adapter Protocol. Les configurations attach fonctionnent quand elles portent un preLaunchTask (la tâche est le travail) ; un attach pur n’a rien à exécuter.

Actions à chaud — la voie rapide à côté de Redémarrer

La plupart des runtimes de développement rechargent déjà sur une touche : flutter run sur r, Metro sur r, nodemon sur rs ⏎, et Vitest relance la suite sur a. Redémarrer la configuration de lancement pour obtenir la même chose, c'est la voie lente : cela tue le processus, rejoue chaque preLaunchTask et jette l'état de l'application.

Gitcito lit donc la commande qu'une configuration lance réellement — en suivant un npm run dev jusqu'aux scripts de votre package.json — et place les touches de ce runtime dans la barre de débogage. Appuyer sur l'une d'elles écrit la touche sur l'entrée standard de la session, exactement comme si vous l'aviez tapée dans le terminal.

Les runtimes qui rechargent d'eux-mêmes n'ont pas de boutons — node --watch, ng serve, tsc --watch, cargo watch, next dev, webpack-dev-server. Un bouton qui envoie une touche que personne ne lit est pire que pas de bouton, parce qu'il a l'air d'avoir marché.

Les limites. La détection est textuelle : elle cherche le nom du programme dans la ligne de commande, donc une configuration qui démarre votre serveur via un script d'enrobage que Gitcito ne peut pas lire n'obtient rien. Rien n'accuse réception non plus : le bouton clignote, et la sortie du processus est la vraie réponse. Une session en pause ou terminée n'accepte aucune entrée, les boutons sont alors grisés.

Quand la déduction se trompe, dites-le dans la configuration elle-même :

{
  "name": "API (watch)",
  "type": "node-terminal",
  "command": "./scripts/dev.sh",
  "gitcito": { "hotActions": [{ "label": "Reload", "send": "r", "icon": "reload" }] }
}

send est écrit tel quel — terminez-le par \n pour une CLI qui attend Entrée. icon est facultatif : reload, restart, rerun, failed, snapshot, menu, debugger, browser, clear, paint, perf, platform, devtools, urls. Un tableau hotActions vide désactive les boutons pour cette configuration.

Cible d’exécution — sur quel appareil une configuration démarre

À une configuration qui construit une application mobile, il faut dire où l’exécuter. Ce choix n’appartient pas qu’à Flutter — React Native, Expo, Capacitor et xcodebuild prennent aussi une cible, chacun à sa façon. Gitcito la demande donc une seule fois, à côté de l’onglet LAUNCH, et écrit la réponse dans la forme que lit le runtime de cette configuration. Le sélecteur n’apparaît que si une configuration du dépôt peut réellement prendre un appareil.

D’où vient la liste — des outils du SDK présents sur la machine, interrogés en parallèle :

Le même simulateur est signalé par jusqu’à trois d’entre eux : les entrées sont fusionnées par plateforme et par nom, et Flutter l’emporte en cas d’égalité, car son identifiant est celui qu’attend flutter run -d. Les outils absents sont nommés en bas du menu — une liste courte doit s’expliquer elle-même.

Ce que fait le choix :

Toute configuration lancée reçoit en plus GITCITO_DEVICE_ID, GITCITO_DEVICE_NAME et GITCITO_DEVICE_PLATFORM dans son environnement, ainsi que ANDROID_SERIAL quand la cible est un vrai appareil Android. C’est ce qui permet à un script d’enrobage, à une tâche Gradle ou à un simple adb de viser le même téléphone sans que Gitcito réécrive quoi que ce soit.

Démarrer un appareil froid. Tout ce qui est sous Non démarré démarre quand vous le choisissez : flutter emulators --launch, xcrun simctl boot (plus la fenêtre du Simulator) ou emulator -avd détaché — quitter Gitcito n’emporte donc pas votre émulateur Android.

Les limites. Une configuration qui nomme déjà un appareil — un -d explicite, un --simulator, le deviceId de Dart-Code — est laissée telle quelle : le sélecteur n’écrase jamais ce qu’a écrit l’auteur. Un identifiant qui nécessiterait des guillemets bascule vers l’environnement plutôt que de risquer une ligne de commande cassée. Le menu est filtré selon ce que vos configurations peuvent atteindre : un dépôt uniquement Android ne vous proposera jamais un iPhone. Et la liste est un instantané : branchez un téléphone puis appuyez sur Actualiser les appareils.

Le choix est mémorisé par dépôt, et oublié quand l’appareil cesse d’exister.

Voir aussi : Terminal intégré

Valeurs depuis JSON et YAML

Un champ peut afficher la version actuelle ou préremplir une valeur depuis un fichier du projet. Gitcito lit le fichier au lancement, avant les champs. Aucune extension VS Code n’est nécessaire.

Ajoutez fileValues à un champ promptString ou pickString. Chaque valeur définit un chemin relatif au dossier de la configuration de lancement et une propriété séparée par des points. Utilisez ${fileValue:name} dans description ou default. Un default vide garde le champ facultatif.

{
  "id": "version",
  "type": "promptString",
  "description": "Current: ${fileValue:version} (${fileValue:build})",
  "default": "",
  "fileValues": {
    "version": { "file": "version.yaml", "key": "settings.base.MARKETING_VERSION" },
    "build": { "file": "version.yaml", "key": "settings.base.CURRENT_PROJECT_VERSION" }
  }
}

Seuls les fichiers JSON, YAML et YML de ce dossier, de 1 Mio maximum, sont acceptés. Les valeurs doivent être des chaînes, nombres ou booléens. Un fichier absent, des données incorrectes, une propriété manquante ou un chemin externe interrompent le lancement avec une erreur. Aucune commande ni expression JavaScript n’est exécutée. Chaque nouveau lancement relit les fichiers ; Restart réutilise les réponses. VS Code ne résout pas nativement ces champs Gitcito.