Uruchamianie i debugowanie

Gitcito czyta twój .vscode/launch.json — ten z korzenia oraz wszystkie zagnieżdżone, pogrupowane separatorami — i uruchamia wybraną przez ciebie konfigurację we wbudowanym terminalu.

• Zmienne VS Code są rozwiązywane (${workspaceFolder} i spółka).
• preLaunchTask danej konfiguracji uruchamia się jako pierwsze.
• Wartości ${input:…} są odpytywane interaktywnie przed uruchomieniem (promptString i pickString). pickString pokazuje opcje jako prawdziwy wybierak z zaznaczoną wartością domyślną; promptString oznaczony password jest maskowany.
• Zadania isBackground (watchery, serwery deweloperskie) działają odczepione, więc nigdy nie blokują uruchomienia.
• Compoundy uruchamiają każdego członka jako osobną równoległą sesję, w jednym podzielonym terminalu o nazwie compoundu — jeden panel na członka, dokładnie jak sesje debugowania w VS Code. Z stopAll: true zatrzymanie jednego członka zatrzymuje wszystkie. Zadania wspólne dla kilku członków uruchamiają się raz, we własnym panelu, zanim wystartują członkowie — prompt podbicia wersji pyta raz, a nie raz na członka. Ten panel zamyka się sam po sukcesie, a przy błędzie zostaje otwarty.
• serverReadyAction jest honorowane: gdy wyjście sesji pasuje do skonfigurowanego wzorca, ogłoszony URL otwiera się w przeglądarce (openExternally; debugWithChrome / debugWithEdge również otwierają przeglądarkę — Gitcito nie może podłączyć do niej debugera).

Pływający pasek narzędzi daje ci pauzę / wznowienie, restart, zatrzymanie i przełącza między działającymi sesjami.

Włącz to w Ustawienia → Ogólne → Włącz launch.json. Przycisk LAUNCH pojawia się obok zakładek Git / Pliki.

Członek compoundu wyświetla się jako compound › członek, a jego restart restartuje tylko tego członka. Jeśli pasek zasłania coś, czego potrzebujesz, przeciągnij go w bok za uchwyt — pozycja jest zapamiętywana, a podwójne kliknięcie uchwytu ponownie go wyśrodkowuje.

Czego Gitcito celowo nie robi: uruchamia programy w prawdziwych terminalach, ale nie jest debugerem — bez breakpointów, bez podglądu zmiennych, bez Debug Adapter Protocol. Konfiguracje typu attach działają, gdy niosą preLaunchTask (zadanie jest pracą); czysty attach nie ma nic do uruchomienia.

Akcje na gorąco — szybka ścieżka obok Uruchom ponownie

Większość środowisk deweloperskich przeładowuje się jednym klawiszem: flutter run na r, Metro na r, nodemon na rs ⏎, a Vitest uruchamia zestaw ponownie na a. Restart konfiguracji uruchamiania, żeby osiągnąć to samo, to droga wolna — zabija proces, uruchamia ponownie każdy preLaunchTask i wyrzuca stan aplikacji.

Dlatego Gitcito czyta polecenie, które konfiguracja naprawdę uruchamia — idąc za npm run dev aż do skryptów w twoim package.json — i umieszcza klawisze tego środowiska na pasku debugowania. Naciśnięcie zapisuje klawisz na standardowe wejście sesji, dokładnie tak, jakbyś wpisał go w terminalu.

Środowiska, które przeładowują się same, nie dostają przycisków — node --watch, ng serve, tsc --watch, cargo watch, next dev, webpack-dev-server. Przycisk wysyłający klawisz, którego nikt nie czyta, jest gorszy niż brak przycisku, bo wygląda, jakby zadziałał.

Ograniczenia. Wykrywanie jest tekstowe: dopasowuje nazwę programu w linii poleceń, więc konfiguracja, która startuje serwer przez skrypt opakowujący, którego Gitcito nie potrafi odczytać, nie dostanie nic. Nie ma też potwierdzenia — przycisk mignie, a prawdziwą odpowiedzią jest wyjście samego procesu. Sesja wstrzymana lub zakończona nie przyjmuje wejścia, więc przyciski są wyszarzone.

Gdy zgadywanie zawodzi, powiedz to w samej konfiguracji:

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

send jest zapisywane dosłownie — zakończ je \n dla CLI czekającego na Enter. icon jest opcjonalne: reload, restart, rerun, failed, snapshot, menu, debugger, browser, clear, paint, perf, platform, devtools, urls. Pusta tablica hotActions wyłącza przyciski dla tej konfiguracji.

Cel uruchomienia — na jakim urządzeniu startuje konfiguracja

Konfiguracji, która buduje aplikację mobilną, trzeba powiedzieć, gdzie ma ją uruchomić. Ten wybór nie należy tylko do Fluttera — React Native, Expo, Capacitor i xcodebuild też przyjmują cel, każdy zapisywany inaczej. Dlatego Gitcito pyta raz, obok zakładki LAUNCH, i zapisuje odpowiedź w formie, którą czyta środowisko tej konfiguracji. Selektor pojawia się tylko wtedy, gdy któraś konfiguracja w repozytorium faktycznie przyjmuje urządzenie.

Skąd bierze się lista — z tych narzędzi SDK, które są na maszynie, pytanych równolegle:

Ten sam symulator zgłaszają nawet trzy z nich, więc wpisy są łączone po platformie i nazwie; przy remisie wygrywa Flutter, bo jego id jest tym, którego oczekuje flutter run -d. Niezainstalowane narzędzia wymieniamy na dole menu — krótka lista powinna sama się tłumaczyć.

Co robi wybór:

Każda uruchomiona konfiguracja dostaje też GITCITO_DEVICE_ID, GITCITO_DEVICE_NAME i GITCITO_DEVICE_PLATFORM w środowisku, a przy prawdziwym urządzeniu z Androidem również ANDROID_SERIAL. To właśnie pozwala skryptowi opakowującemu, zadaniu Gradle albo gołemu adb trafić w ten sam telefon, bez przepisywania czegokolwiek przez Gitcito.

Uruchamianie zimnego urządzenia. Wszystko pod Nieuruchomione startuje po wybraniu: flutter emulators --launch, xcrun simctl boot (plus okno Simulatora) albo odłączony emulator -avd — dzięki temu zamknięcie Gitcito nie zabiera ze sobą twojego emulatora Androida.

Ograniczenia. Konfiguracja, która już nazywa urządzenie — jawne -d, --simulator, deviceId z Dart-Code — zostaje nietknięta: selektor nigdy nie nadpisuje tego, co napisał autor. Id, które wymagałoby cudzysłowów, trafia do środowiska, zamiast ryzykować zepsutą linię poleceń. Menu jest filtrowane do tego, co twoje konfiguracje mogą osiągnąć, więc repozytorium tylko z Androidem nigdy nie zaproponuje ci iPhone’a. A lista to zdjęcie chwili: podłącz telefon i naciśnij Odśwież urządzenia.

Wybór jest pamiętany dla każdego repozytorium i zapominany, gdy urządzenie przestaje istnieć.

Zobacz też: Wbudowany terminal

Wartości z JSON i YAML

Pole może pokazywać bieżącą wersję lub pobierać wartość początkową z pliku projektu. Gitcito odczytuje plik przy uruchamianiu, przed wyświetleniem pól. Rozszerzenie VS Code nie jest potrzebne.

Dodaj fileValues do pola promptString lub pickString. Każda wartość określa ścieżkę względem folderu konfiguracji uruchamiania oraz właściwość rozdzieloną kropkami. Użyj ${fileValue:name} w description lub default. Pusty default pozostawia pole opcjonalne.

{
  "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" }
  }
}

Obsługiwane są pliki JSON, YAML i YML w tym folderze do 1 MiB oraz tekst, liczby i wartości logiczne. Brak pliku, błędne dane, brak właściwości lub ścieżka zewnętrzna zatrzymują uruchomienie z błędem. Polecenia i wyrażenia JavaScript nie są wykonywane. Nowe uruchomienie ponownie odczytuje pliki; Restart używa poprzednich odpowiedzi. VS Code nie obsługuje tych pól Gitcito natywnie.