Skip to main content

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 logoUrl e screenshots em defineApplication() 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çõesyarn twenty build agrupa 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
Em um componente de front-end:
src/front-components/company-card.tsx
O argumento 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 — nenhum node_modules é necessário em tempo de execução.

Instalando um pacote

Em seguida, importe-o no seu código:
src/logic-functions/fetch-data.ts
O mesmo vale para componentes de front-end:
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:
Crie um vitest.config.ts na raiz do seu aplicativo:
vitest.config.ts
Crie um arquivo de configuração que verifique se o servidor está acessível antes da execução dos testes:
src/__tests__/setup-test.ts

APIs programáticas do SDK

O subcaminho twenty-sdk/cli exporta funções que você pode chamar diretamente a partir do código de teste: Cada função retorna um objeto de resultado com 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:
Ou no modo watch durante o desenvolvimento:

Verificação de tipos

Você também pode executar a verificação de tipos no seu aplicativo sem executar os testes:
Isso executa tsc --noEmit e informa quaisquer erros de tipo.

Referência da CLI

Além de dev, 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.
Suas credenciais são armazenadas em ~/.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:
  1. Faz checkout do seu código
  2. Inicializa um servidor Twenty temporário usando a ação twentyhq/twenty/.github/actions/spawn-twenty-docker-image
  3. Instala as dependências com yarn install --immutable
  4. Executa yarn test com TWENTY_API_URL e TWENTY_API_KEY injetados a partir das saídas da ação
.github/workflows/ci.yml
Você não precisa configurar nenhum segredo — a ação 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.