Öffentliche Assets (Ordner public/)
Der Ordner public/ im Stammverzeichnis Ihrer App enthält statische Dateien — Bilder, Icons, Schriftarten oder sonstige Assets, die Ihre App zur Laufzeit benötigt. Diese Dateien werden automatisch in Builds aufgenommen, während des Dev-Modus synchronisiert und auf den Server hochgeladen.
Für Dateien im Verzeichnis public/ gilt:
- Öffentlich zugänglich — nach der Synchronisierung mit dem Server werden Assets unter einer öffentlichen URL bereitgestellt. Zum Zugriff ist keine Authentifizierung erforderlich.
- In Frontend-Komponenten verfügbar — verwenden Sie Asset-URLs, um Bilder, Icons oder andere Medien in Ihren React-Komponenten anzuzeigen.
- In Logikfunktionen verfügbar — referenzieren Sie Asset-URLs in E-Mails, API-Antworten oder in beliebiger serverseitiger Logik.
- Für Marketplace-Metadaten verwendet — die Felder
logoUrlundscreenshotsindefineApplication()referenzieren Dateien aus diesem Ordner (z. B.public/logo.png). Diese werden im Marketplace angezeigt, wenn Ihre App veröffentlicht wird. - Im Dev-Modus automatisch synchronisiert — wenn Sie in
public/eine Datei hinzufügen, aktualisieren oder löschen, wird sie automatisch mit dem Server synchronisiert. Kein Neustart erforderlich. - In Builds enthalten —
yarn twenty buildbündelt alle öffentlichen Assets in der Distributionsausgabe.
Zugriff auf öffentliche Assets mit getPublicAssetUrl
Verwenden Sie den Helper getPublicAssetUrl aus twenty-sdk, um die vollständige URL einer Datei in Ihrem public/-Verzeichnis zu erhalten. Dies funktioniert sowohl in Logikfunktionen als auch in Frontend-Komponenten.
In einer Logikfunktion:
src/logic-functions/send-invoice.ts
src/front-components/company-card.tsx
path ist relativ zum public/-Ordner Ihrer App. Sowohl getPublicAssetUrl('logo.png') als auch getPublicAssetUrl('public/logo.png') ergeben dieselbe URL — das Präfix public/ wird, falls vorhanden, automatisch entfernt.
Verwendung von npm-Paketen
Sie können in Ihrer App beliebige npm-Pakete installieren und verwenden. Sowohl Logikfunktionen als auch Frontend-Komponenten werden mit esbuild gebündelt, das alle Abhängigkeiten in die Ausgabe einbettet — zur Laufzeit sind keinenode_modules erforderlich.
Ein Paket installieren
src/logic-functions/fetch-data.ts
src/front-components/chart.tsx
Wie das Bundling funktioniert
Der Build-Schritt verwendet esbuild, um pro Logikfunktion und pro Frontend-Komponente eine einzelne, in sich geschlossene Datei zu erzeugen. Alle importierten Pakete werden in das Bundle eingebettet. Logikfunktionen laufen in einer Node.js-Umgebung. Eingebaute Node.js-Module (fs, path, crypto, http usw.) stehen zur Verfügung und müssen nicht installiert werden.
Frontend-Komponenten laufen in einem Web Worker. Eingebaute Node.js-Module sind nicht verfügbar — nur Browser-APIs und npm-Pakete, die in einer Browserumgebung funktionieren.
In beiden Umgebungen stehen twenty-client-sdk/core und twenty-client-sdk/metadata als vorab bereitgestellte Module zur Verfügung — sie werden nicht gebündelt, sondern zur Laufzeit vom Server aufgelöst.
Ihre App testen
Das SDK stellt programmgesteuerte APIs bereit, mit denen Sie Ihre App aus Testcode heraus bauen, bereitstellen, installieren und deinstallieren können. In Kombination mit Vitest und den typisierten API-Clients können Sie Integrationstests schreiben, die prüfen, dass Ihre App End-to-End gegen einen echten Twenty-Server funktioniert.Einrichtung
Die erzeugte App enthält bereits Vitest. Wenn Sie es manuell einrichten, installieren Sie die Abhängigkeiten:vitest.config.ts im Stammverzeichnis Ihrer App:
vitest.config.ts
src/__tests__/setup-test.ts
Programmgesteuerte SDK-APIs
Der Subpfadtwenty-sdk/cli exportiert Funktionen, die Sie direkt aus Testcode aufrufen können:
| Funktion | Beschreibung |
|---|---|
appBuild | Die App bauen und optional ein Tarball packen |
appDeploy | Ein Tarball auf den Server hochladen |
appInstall | Die App im aktiven Arbeitsbereich installieren |
appUninstall | Die App aus dem aktiven Arbeitsbereich deinstallieren |
success: boolean und entweder data oder error zurück.
Einen Integrationstest schreiben
Hier ist ein vollständiges Beispiel, das die App baut, bereitstellt und installiert und anschließend prüft, dass sie im Arbeitsbereich erscheint:src/__tests__/app-install.integration-test.ts
Tests ausführen
Stellen Sie sicher, dass Ihr lokaler Twenty-Server läuft, und führen Sie dann Folgendes aus:Typprüfung
Sie können die Typprüfung Ihrer App auch ohne Tests ausführen:tsc --noEmit aus und meldet etwaige Typfehler.
CLI-Referenz
Zusätzlich zudev, build, add und typecheck bietet die CLI Befehle zum Ausführen von Funktionen, Anzeigen von Logs und Verwalten von App-Installationen.
Funktionen ausführen (yarn twenty exec)
Eine Logikfunktion manuell ausführen, ohne sie über HTTP, Cron oder ein Datenbankereignis auszulösen:
Funktionsprotokolle ansehen (yarn twenty logs)
Ausführungsprotokolle für die Logikfunktionen Ihrer App streamen:
Dies unterscheidet sich von
yarn twenty server logs, das die Docker-Container-Logs anzeigt. yarn twenty logs zeigt die Funktionsausführungsprotokolle Ihrer App vom Twenty-Server.Eine App deinstallieren (yarn twenty uninstall)
Entfernen Sie Ihre App aus dem aktiven Arbeitsbereich:
Remotes verwalten
Ein Remote ist ein Twenty-Server, mit dem sich Ihre App verbindet. Während der Einrichtung erstellt das Scaffolding-Tool automatisch eines für Sie. Sie können jederzeit weitere Remotes hinzufügen oder zwischen ihnen wechseln.~/.twenty/config.json gespeichert.
CI mit GitHub Actions
Das Scaffolding-Tool erzeugt einen einsatzbereiten GitHub-Actions-Workflow in.github/workflows/ci.yml. Er führt Ihre Integrationstests automatisch bei jedem Push auf main und bei Pull Requests aus.
Der Workflow:
- Checkt Ihren Code aus
- Startet einen temporären Twenty-Server mit der Aktion
twentyhq/twenty/.github/actions/spawn-twenty-docker-image - Installiert Abhängigkeiten mit
yarn install --immutable - Führt
yarn testaus, wobeiTWENTY_API_URLundTWENTY_API_KEYaus den Aktionsausgaben injiziert werden.
.github/workflows/ci.yml
spawn-twenty-docker-image startet einen flüchtigen Twenty-Server direkt im Runner und gibt die Verbindungsdetails aus. Das Secret GITHUB_TOKEN wird automatisch von GitHub bereitgestellt.
Um eine bestimmte Twenty-Version statt latest festzulegen, ändern Sie die Umgebungsvariable TWENTY_VERSION oben im Workflow.