Lokale Entwicklung

Voraussetzungen

• Node.js und das Programm, das der Build-Befehl startet, etwa npm, in deinem PATH. Fehlt etwas davon, nennt connic dev es und baut die App nicht.
• Die Abhängigkeiten der App in apps/<key>/ installiert, etwa mit npm install. connic dev führt nur build.command aus, nicht den Installationsbefehl.
• Ein Projekt in einem Tarif, der Apps enthält.

So funktioniert es

1. 1

   connic dev lädt das Projekt hoch, mit apps/*.yaml und connectors/*.yaml, aber ohne den Quellcode der Apps.

2. 2

   connic legt die Connectors und Apps aus diesen Dateien im Dev-Environment an, ändert sie oder legt sie still, wie bei der Aktivierung eines Deployments, samt Anmeldung, Custom Domains und Zugriffsregeln.

3. 3

   Für jede App führt connic dev build.command in apps/<key>/ aus, lädt den Ordner build.output hoch und gibt die URL der App im Dev-Environment aus.

→ Building app portal...
    ✓ portal → https://portal-7e21c09f.connic.app

Das Dev-Environment hat eine eigene App mit eigener URL, die bei einem wiederverwendbaren Dev-Environment gleich bleibt. Dev-Builds werden nicht gecacht, ein Neuladen zeigt also den neuesten. Es gelten dieselben Limits wie bei Deployments: eine index.html im Ausgabeordner und die Ausgabegröße pro App aus dem Tarif.

Apps mit environments

Eine Datei ohne environments erreicht jedes Dev-Environment. Eine Datei mit environments erreicht ein Dev-Environment nur, wenn die Liste es nennt oder die Datei dev setzt. dev gilt für jedes Dev-Environment, das die Liste nicht nennt, kurze Tests eingeschlossen, mit denselben Feldern wie ein Override pro Environment. dev: {} übernimmt den Kopf der Datei unverändert.

environments:
  Staging:
    auth:
      mode: connic
  Production: {}
dev:                              # jedes Dev-Environment, das die Liste nicht nennt
  auth:
    mode: connic

Dev-Environments haben eigene Variablen, und ein kurzer Test startet ganz ohne. Einstellungen, die anderswo Variablen lesen, etwa die OIDC-Anmeldung, gehören deshalb in dev. Eine Custom Domain bedient ein einziges Environment; setzt der Kopf der Datei eine, setze domain: null in dev. Die Connectors, die die App auflistet, brauchen ebenfalls dev in ihren Dateien, wenn diese Dateien environments auflisten.

Eine App, die das Dev-Environment nicht bekommt, baut connic dev nicht und nennt den Grund:

! portal: apps/portal.yaml doesn't list test-swift-fox-ab12 in environments; add dev to serve it in connic dev

Neue Builds

connic dev beobachtet apps/<key>/ und baut die App neu, wenn sich der Inhalt einer Quelldatei ändert. Ignoriert werden node_modules, versteckte Dateien, der Ausgabeordner sowie die Ordner dist, build, out und coverage. Speicherst du apps/<key>.yaml, gelten die neuen Einstellungen, und eine neue App, eine App, die das Dev-Environment jetzt bekommt, oder geänderte build-Einstellungen starten einen Build.

Ein fehlgeschlagener Build gibt die Ausgabe des Befehls aus, und der letzte funktionierende Build bleibt online:

[14:02:11] → Building app portal...
    ✗ portal: `npm run build` exited with code 1
    src/App.tsx(12,5): error TS2322: Type 'string' is not assignable to type 'number'.
    The last good build stays live at https://portal-7e21c09f.connic.app

Connectors im Dev-Environment

Die Connectors aus connectors/*.yaml werden beim Start der Session und bei jeder Änderung einer Connector-Datei auf das Dev-Environment angewendet, genau wie bei einem Deployment; siehe Verbindungen im Code. Scheitert eine Änderung an einem Connector oder einer App, zeigt connic dev den Fehler, und das Dev-Environment behält seinen vorherigen Stand.