Desenvolvimento Deno com TypeScript usando Claude Code

Trate permissões como parte da arquitetura

Deno não é apenas mais um runtime JavaScript. Ele incentiva permissões explícitas para arquivo, rede, ambiente e processos. Claude Code ajuda a criar APIs, CLIs, automações e testes em Deno, mas o prompt precisa limitar permissões; caso contrário, o agente pode sugerir --allow-all sem necessidade.

Leia também guia de permissões, desenvolvimento de APIs e estratégias de teste. Referências oficiais: Deno docs, Deno permissions e Deno.serve.

Comece pela permissão estreita, não pelo código que funciona

Deno é um runtime que executa JavaScript e TypeScript, ou seja, a base que roda o código. Diferente do Node.js, permissões de leitura de arquivo, escrita de arquivo, rede, variáveis de ambiente e execução de comandos externos vêm fechadas por padrão. A própria documentação de segurança e permissões do Deno trata como princípio liberar explicitamente apenas o acesso necessário.

Vale alinhar os termos primeiro. Permissão é a lista do que o programa pode tocar. deno task é um comando com nome registrado no deno.json. O formatter ajusta o estilo, o linter detecta padrões propensos a bug e o test runner executa os testes escritos com Deno.test(). Como o Deno já traz tudo isso de fábrica, dá para começar pequeno sem adicionar uma pilha de dependências de desenvolvimento.

Prompt para Claude Code

Crie uma pequena HTTP API com Deno.
Não use --allow-all.
Liste permissões mínimas, deno.json task, teste, format e lint.
O código deve ser copiável e incluir pitfall antes do deploy.

Use case checklist

1. JSON API pequena com Deno.serve e permissão de rede limitada.
2. Script de automação que lê uma pasta específica e escreve em saída definida.
3. Webhook receiver com validação de assinatura e tratamento de erro.
4. Ferramenta interna com deno fmt, deno lint e deno test no deno.json.

Código de implementação

{
  "tasks": {
    "dev": "deno run --allow-net=localhost:8000 src/server.ts",
    "test": "deno test --allow-net=localhost:8000",
    "check": "deno fmt --check && deno lint && deno test"
  }
}

// src/server.ts
Deno.serve({ port: 8000 }, (request) => {
  const url = new URL(request.url);

  if (url.pathname !== "/health") {
    return Response.json({ error: "not_found" }, { status: 404 });
  }

  return Response.json({ ok: true, runtime: "deno" });
});

Pitfall checklist

• Usar --allow-all remove boa parte do benefício de Deno.
• --allow-net amplo demais aumenta risco de chamadas externas.
• Pacotes pensados para Node podem exigir teste de compatibilidade.
• Ambiente local e deploy podem ter variáveis e permissões diferentes.
• Código gerado precisa passar por deno fmt, deno lint e deno test.

Verificação

deno task check
deno task dev
curl http://localhost:8000/health

Confirme que a API sobe com permissões mínimas, responde JSON em erro e não acessa arquivos fora do escopo. Peça a Claude Code uma revisão final focada em permissões.

Monetização

Deno é útil para ferramentas internas e APIs pequenas que precisam de segurança operacional. Para aplicar isso em equipe, a página de treinamento e consultoria Claude Code ajuda a montar fluxo de permissões, testes e review.

Matriz de permissões

Antes do deploy, peça a Claude Code uma matriz com task, permissão, escopo, motivo e alternativa. Se a API só precisa de --allow-net=localhost:8000, não libere leitura de arquivos. Se um script só lê ./data, não permita acesso ao projeto inteiro. Essa matriz ajuda segurança, revisão e onboarding.

Adoção em equipe

Na primeira semana, coloque apenas format, lint e test no deno.json. Na segunda, escolha um webhook pequeno ou health API. Na terceira, avalie scripts internos. Em cada etapa, Claude Code deve escrever teste, comando de rollback e riscos conhecidos. Isso evita trocar toda a stack de uma vez.

Métricas operacionais

Deno é valioso quando torna o limite de execução fácil de explicar. Comece por formulários de contato, notificações internas ou relatórios de anúncio. Em cada mudança, peça a Claude Code para revisar permissões desnecessárias, valores que não devem aparecer em logs e variáveis de ambiente.

Nota prática

Testei a API de health sem --allow-all, apenas com permissão de rede local. Separar implementação e revisão de permissões deixou o resultado mais fácil de explicar para o time. O maior ganho foi pedir a permissão mínima desde o primeiro prompt: quando deixei o escopo em aberto, o Claude Code tendeu a abrir --allow-all e a misturar bibliotecas pensadas para Node, o que só apareceu na revisão de segurança.