Asset pubblici (cartella public/)
La cartella public/ alla radice della tua app contiene file statici — immagini, icone, font o qualsiasi altro asset di cui la tua app ha bisogno a runtime. Questi file sono inclusi automaticamente nelle build, sincronizzati durante la modalità di sviluppo e caricati sul server.
I file posizionati in public/ sono:
- Pubblicamente accessibili — una volta sincronizzati sul server, gli asset sono serviti a un URL pubblico. Non è necessaria alcuna autenticazione per accedervi.
- Disponibili nei componenti front-end — usa gli URL degli asset per visualizzare immagini, icone o qualsiasi media all’interno dei tuoi componenti React.
- Disponibili nelle funzioni logiche — fai riferimento agli URL degli asset nelle email, nelle risposte API o in qualsiasi logica lato server.
- Usati per i metadati del marketplace — i campi
logoUrlescreenshotsindefineApplication()fanno riferimento a file di questa cartella (ad es.,public/logo.png). Questi vengono visualizzati nel marketplace quando la tua app viene pubblicata. - Sincronizzati automaticamente in modalità dev — quando aggiungi, aggiorni o elimini un file in
public/, viene sincronizzato automaticamente con il server. Nessun riavvio necessario. - Inclusi nelle build —
yarn twenty buildraggruppa tutti gli asset pubblici nell’output di distribuzione.
Accedere agli asset pubblici con getPublicAssetUrl
Usa l’helper getPublicAssetUrl da twenty-sdk per ottenere l’URL completo di un file nella tua directory public/. Funziona sia nelle funzioni logiche che nei componenti front-end.
In una funzione logica:
src/logic-functions/send-invoice.ts
src/front-components/company-card.tsx
path è relativo alla cartella public/ della tua app. Sia getPublicAssetUrl('logo.png') sia getPublicAssetUrl('public/logo.png') risolvono allo stesso URL — il prefisso public/ viene rimosso automaticamente se presente.
Uso dei pacchetti npm
Puoi installare e usare qualsiasi pacchetto npm nella tua app. Sia le funzioni logiche sia i componenti front-end vengono impacchettati con esbuild, che incorpora tutte le dipendenze nell’output — non sono necessari inode_modules a runtime.
Installazione di un pacchetto
src/logic-functions/fetch-data.ts
src/front-components/chart.tsx
Come funziona il bundling
La fase di build usa esbuild per produrre un singolo file autonomo per ogni funzione logica e per ogni componente front-end. Tutti i pacchetti importati sono incorporati nel bundle. Le funzioni logiche vengono eseguite in un ambiente Node.js. I moduli integrati di Node (fs, path, crypto, http, ecc.) sono disponibili e non necessitano di essere installati.
I componenti front-end vengono eseguiti in un Web Worker. I moduli integrati di Node non sono disponibili — solo le API del browser e i pacchetti npm che funzionano in un ambiente browser.
Entrambi gli ambienti hanno twenty-client-sdk/core e twenty-client-sdk/metadata disponibili come moduli preforniti — questi non vengono inclusi nel bundle ma vengono risolti a runtime dal server.
Testare la tua app
L’SDK fornisce API programmatiche che ti consentono di compilare, distribuire, installare e disinstallare la tua app dal codice di test. In combinazione con Vitest e i client API tipizzati, puoi scrivere test di integrazione che verificano che la tua app funzioni end-to-end contro un server Twenty reale.Impostazione
L’app generata tramite scaffolding include già Vitest. Se la configuri manualmente, installa le dipendenze:vitest.config.ts alla radice della tua app:
vitest.config.ts
src/__tests__/setup-test.ts
API programmatiche dell’SDK
Il sottopercorsotwenty-sdk/cli esporta funzioni che puoi chiamare direttamente dal codice di test:
| Funzione | Descrizione |
|---|---|
appBuild | Compila l’app e, opzionalmente, crea un tarball |
appDeploy | Carica un tarball sul server |
appInstall | Installa l’app nello spazio di lavoro attivo |
appUninstall | Disinstalla l’app dallo spazio di lavoro attivo |
success: boolean e data oppure error.
Scrivere un test di integrazione
Ecco un esempio completo che compila, distribuisce e installa l’app, quindi verifica che compaia nello spazio di lavoro:src/__tests__/app-install.integration-test.ts
Esecuzione dei test
Assicurati che il tuo server Twenty locale sia in esecuzione, quindi:Controllo dei tipi
Puoi anche eseguire il controllo dei tipi sulla tua app senza eseguire i test:tsc --noEmit e riporta eventuali errori di tipo.
Riferimento CLI
Oltre adev, build, add e typecheck, la CLI fornisce comandi per eseguire funzioni, visualizzare i log e gestire le installazioni delle app.
Esecuzione delle funzioni (yarn twenty exec)
Esegui manualmente una funzione logica senza attivarla tramite HTTP, cron o evento del database:
Visualizzazione dei log delle funzioni (yarn twenty logs)
Esegui lo streaming dei log di esecuzione per le funzioni logiche della tua app:
Questo è diverso da
yarn twenty server logs, che mostra i log del container Docker. yarn twenty logs mostra i log di esecuzione delle funzioni della tua app dal server Twenty.Disinstallazione di un’app (yarn twenty uninstall)
Rimuovi la tua app dallo spazio di lavoro attivo:
Gestione dei remoti
Un remoto è un server Twenty a cui la tua app si connette. Durante la configurazione, lo strumento di scaffolding ne crea uno automaticamente per te. Puoi aggiungere altri remoti o passare da uno all’altro in qualsiasi momento.~/.twenty/config.json.
CI con GitHub Actions
Lo strumento di scaffolding genera un workflow GitHub Actions pronto all’uso in.github/workflows/ci.yml. Esegue automaticamente i test di integrazione a ogni push su main e sulle pull request.
Il workflow:
- Esegue il checkout del tuo codice
- Avvia un server Twenty temporaneo utilizzando l’azione
twentyhq/twenty/.github/actions/spawn-twenty-docker-image - Installa le dipendenze con
yarn install --immutable - Esegue
yarn testconTWENTY_API_URLeTWENTY_API_KEYiniettati dagli output dell’azione
.github/workflows/ci.yml
spawn-twenty-docker-image avvia un server Twenty effimero direttamente nel runner e fornisce i dettagli di connessione. Il secret GITHUB_TOKEN è fornito automaticamente da GitHub.
Per fissare una versione specifica di Twenty invece di latest, modifica la variabile d’ambiente TWENTY_VERSION all’inizio del workflow.