Skip to main content

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 logoUrl e screenshots in defineApplication() 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 buildyarn twenty build raggruppa 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
In un componente front-end:
src/front-components/company-card.tsx
L’argomento 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 i node_modules a runtime.

Installazione di un pacchetto

Quindi importalo nel tuo codice:
src/logic-functions/fetch-data.ts
Lo stesso vale per i componenti front-end:
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:
Crea un vitest.config.ts alla radice della tua app:
vitest.config.ts
Crea un file di setup che verifichi che il server sia raggiungibile prima dell’esecuzione dei test:
src/__tests__/setup-test.ts

API programmatiche dell’SDK

Il sottopercorso twenty-sdk/cli esporta funzioni che puoi chiamare direttamente dal codice di test: Ogni funzione restituisce un oggetto risultato con 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:
Oppure in modalità watch durante lo sviluppo:

Controllo dei tipi

Puoi anche eseguire il controllo dei tipi sulla tua app senza eseguire i test:
Questo esegue tsc --noEmit e riporta eventuali errori di tipo.

Riferimento CLI

Oltre a dev, 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.
Le tue credenziali sono archiviate in ~/.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:
  1. Esegue il checkout del tuo codice
  2. Avvia un server Twenty temporaneo utilizzando l’azione twentyhq/twenty/.github/actions/spawn-twenty-docker-image
  3. Installa le dipendenze con yarn install --immutable
  4. Esegue yarn test con TWENTY_API_URL e TWENTY_API_KEY iniettati dagli output dell’azione
.github/workflows/ci.yml
Non è necessario configurare alcun secret — l’azione 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.