Recursos públicos (pasta public/)
A pasta public/ na raiz do seu app contém arquivos estáticos — imagens, ícones, fontes ou quaisquer outros recursos de que seu app precisa em tempo de execução. Esses arquivos são incluídos automaticamente nas compilações, sincronizados durante o modo de desenvolvimento e enviados para o servidor.
Arquivos colocados em public/ são:
- Publicamente acessíveis — depois de sincronizados com o servidor, os recursos são servidos em uma URL pública. Não é necessária autenticação para acessá-los.
- Disponíveis em componentes de front-end — use URLs de recursos para exibir imagens, ícones ou qualquer mídia dentro de seus componentes React.
- Disponíveis em funções lógicas — referencie URLs de recursos em e-mails, respostas de API ou qualquer lógica no lado do servidor.
- Usados para metadados do marketplace — os campos
logoUrlescreenshotsemdefineApplication()referenciam arquivos desta pasta (por exemplo,public/logo.png). Eles são exibidos no marketplace quando seu app é publicado. - Sincronizados automaticamente no modo de desenvolvimento — quando você adiciona, atualiza ou exclui um arquivo em
public/, ele é sincronizado automaticamente com o servidor. Não é necessário reiniciar. - Incluídos nas compilações —
yarn twenty buildagrupa todos os recursos públicos na saída de distribuição.
Acessando recursos públicos com getPublicAssetUrl
Use o helper getPublicAssetUrl de twenty-sdk para obter a URL completa de um arquivo no seu diretório public/. Funciona tanto em funções lógicas quanto em componentes de front-end.
Em uma função lógica:
src/logic-functions/send-invoice.ts
src/front-components/company-card.tsx
path é relativo à pasta public/ do seu app. Tanto getPublicAssetUrl('logo.png') quanto getPublicAssetUrl('public/logo.png') resolvem para a mesma URL — o prefixo public/ é removido automaticamente, se presente.
Usando pacotes npm
Você pode instalar e usar qualquer pacote npm no seu app. Tanto funções lógicas quanto componentes de front-end são empacotados com esbuild, que incorpora todas as dependências na saída — nenhumnode_modules é necessário em tempo de execução.
Instalando um pacote
src/logic-functions/fetch-data.ts
src/front-components/chart.tsx
Como o empacotamento funciona
A etapa de build usa o esbuild para produzir um único arquivo independente por função lógica e por componente de front-end. Todos os pacotes importados são incorporados ao bundle. Funções lógicas são executadas em um ambiente Node.js. Módulos nativos do Node (fs, path, crypto, http, etc.) estão disponíveis e não precisam ser instalados.
Componentes de front-end são executados em um Web Worker. Módulos nativos do Node não estão disponíveis — apenas APIs do navegador e pacotes npm que funcionam em um ambiente de navegador.
Ambos os ambientes têm twenty-client-sdk/core e twenty-client-sdk/metadata disponíveis como módulos pré-fornecidos — eles não são empacotados, mas resolvidos em tempo de execução pelo servidor.
Testando seu aplicativo
O SDK fornece APIs programáticas que permitem compilar, implantar, instalar e desinstalar seu aplicativo a partir de código de teste. Em conjunto com Vitest e os clientes de API tipados, você pode escrever testes de integração que verificam que seu aplicativo funciona de ponta a ponta em um servidor Twenty real.Configuração
O aplicativo gerado pelo scaffolder já inclui o Vitest. Se você configurá-lo manualmente, instale as dependências:vitest.config.ts na raiz do seu aplicativo:
vitest.config.ts
src/__tests__/setup-test.ts
APIs programáticas do SDK
O subcaminhotwenty-sdk/cli exporta funções que você pode chamar diretamente a partir do código de teste:
| Função | Descrição |
|---|---|
appBuild | Compilar o aplicativo e, opcionalmente, empacotar um tarball |
appDeploy | Enviar um tarball para o servidor |
appInstall | Instalar o aplicativo no espaço de trabalho ativo |
appUninstall | Desinstalar o aplicativo do espaço de trabalho ativo |
success: boolean e data ou error.
Escrevendo um teste de integração
Aqui está um exemplo completo que compila, implanta e instala o aplicativo e, em seguida, verifica se ele aparece no espaço de trabalho:src/__tests__/app-install.integration-test.ts
Executando testes
Certifique-se de que seu servidor Twenty local esteja em execução e, em seguida:Verificação de tipos
Você também pode executar a verificação de tipos no seu aplicativo sem executar os testes:tsc --noEmit e informa quaisquer erros de tipo.
Referência da CLI
Além dedev, build, add e typecheck, a CLI fornece comandos para executar funções, visualizar logs e gerenciar instalações de aplicativos.
Executando funções (yarn twenty exec)
Execute manualmente uma função de lógica sem acioná-la via HTTP, cron ou evento de banco de dados:
Visualizando logs de funções (yarn twenty logs)
Transmita os logs de execução das funções de lógica do seu aplicativo:
Isso é diferente de
yarn twenty server logs, que mostra os logs do contêiner Docker. yarn twenty logs mostra os logs de execução de funções do seu aplicativo a partir do servidor Twenty.Desinstalando um aplicativo (yarn twenty uninstall)
Remova seu aplicativo do espaço de trabalho ativo:
Gerenciando remotos
Um remoto é um servidor Twenty ao qual seu aplicativo se conecta. Durante a configuração, o gerador de scaffold cria um para você automaticamente. Você pode adicionar mais remotos ou alternar entre eles a qualquer momento.~/.twenty/config.json.
CI com GitHub Actions
O gerador de scaffold cria um workflow do GitHub Actions pronto para uso em.github/workflows/ci.yml. Ele executa seus testes de integração automaticamente a cada push para main e em pull requests.
O workflow:
- Faz checkout do seu código
- Inicializa um servidor Twenty temporário usando a ação
twentyhq/twenty/.github/actions/spawn-twenty-docker-image - Instala as dependências com
yarn install --immutable - Executa
yarn testcomTWENTY_API_URLeTWENTY_API_KEYinjetados a partir das saídas da ação
.github/workflows/ci.yml
spawn-twenty-docker-image inicia um servidor Twenty efêmero diretamente no runner e fornece os detalhes de conexão. O segredo GITHUB_TOKEN é fornecido automaticamente pelo GitHub.
Para fixar uma versão específica do Twenty em vez de latest, altere a variável de ambiente TWENTY_VERSION no topo do workflow.