Você já passou por aquela situação trágica de adicionar uma coluna nova no banco de dados e esquecer de atualizar a interface do TypeScript? O código quebra na produção, o tech lead chora, e você se pergunta por que a vida de dev tem que ser assim. Pois é, eu também. Mas hoje vamos falar sobre uma ferramenta que resolve exatamente isso de forma brilhante unindo Kanel PostgreSQL: o framework que vai salvar o seu fluxo de trabalho.
O que é o Kanel?
De forma bem direta, o Kanel é um framework de geração de código que transforma o seu esquema do PostgreSQL em vários formatos de saída.
Ele atua como uma espécie de “ORM reverso”. Em vez de você escrever seus tipos e modelos em TypeScript e rezar para o banco de dados estar alinhado (ou usar migrações complexas que saem do controle), o Kanel faz o oposto. Com ele, o seu banco de dados PostgreSQL é a única fonte da verdade.
Por que você deveria usá-lo? (Ou “Why Kanel?”)
Se você ainda não está convencido a deixar de escrever tipos manualmente, aqui estão alguns motivos para adotar a ferramenta:
- O Banco é o Rei: O seu esquema do banco de dados dita quais serão os seus tipos, e não o contrário.
- Type Safety de Verdade: Ele gera tipos TypeScript precisos e impecáveis, lidando facilmente com chaves primárias (branded IDs), nulabilidade e relações entre tabelas.
- Extensível e Flexível: Você não está preso a um formato único. O Kanel permite integração com bibliotecas famosas (Kysely, Zod, Knex) através de ganchos (hooks) e suporta a criação de geradores customizados para linguagens como Python, Rust, ou GraphQL.
- Fluxo de Trabalho Descomplicado: O código gerado não é um artefato mágico intocável; você deve fazer o commit dele no seu controle de versão (Git) e tratá-lo como parte nativa do seu projeto.
Como Funciona: A Mágica dos Geradores
O Kanel não chuta os tipos; ele se conecta e inspeciona um banco de dados PostgreSQL ao vivo para extrair o esquema.
A arquitetura da versão 4 do Kanel brilha por conta do seu sistema plugável de geradores:
- PgTsGenerator: Este é o “arroz com feijão” do framework. É o gerador responsável pelo caso de uso mais comum: criar os seus amados tipos em TypeScript.
- MarkdownGenerator: Ideal para gerar documentação amigável para humanos ou para o seu LLM de estimação ler.
- Custom Generators: Você mesmo pode escrever o seu gerador para qualquer outra linguagem ou formato bizarro que a sua empresa inventar.
| Funcionalidade | Descrição | Caso de Uso | Gerador Associado | Extensões Suportadas |
| Geração de Tipos TypeScript | Transforma o esquema do banco de dados PostgreSQL em definições de tipos TypeScript precisas, incluindo IDs marcados e relações. | Garantir segurança de tipos ponta a ponta no backend sincronizado com o banco de dados. | PgTsGenerator | Kysely, Knex, Zod |
| Geração de Esquemas de Validação | Gera esquemas de validação Zod integrados aos tipos TypeScript extraídos do banco de dados. | Validar dados de entrada em APIs garantindo que correspondam às restrições do PostgreSQL. | PgTsGenerator | kanel-zod |
| Integração com Query Builders | Fornece interfaces de banco de dados para construtores de consultas SQL populares. | Desenvolvimento de consultas SQL com suporte completo de autocompletar e tipagem. | PgTsGenerator | kanel-knex, kanel-kysely |
| Geração de Documentação | Cria documentação legível por humanos ou LLMs a partir do esquema do banco de dados. | Manter documentação técnica do banco de dados sempre atualizada sem esforço manual. | MarkdownGenerator | Markdown (.md) |
| Arquitetura de Geradores Customizáveis | Sistema plugável que permite a criação de novos geradores para diferentes linguagens ou formatos. | Gerar código para Python, Rust, GraphQL ou outros formatos customizados. | Custom generators | Qualquer extensão via hooks |
Casos de Uso e Exemplos Práticos
O Kanel se adapta perfeitamente ao stack que você já usa no backend. Vamos ver como ele se comporta nos cenários (e integrações) mais comuns no dia a dia:
1. A Dupla Dinâmica: TypeScript + Kysely
Se você usa o Kysely (um query builder type-safe sensacional), você já sabe que ele precisa de interfaces que mapeiem exatamente o banco de dados para garantir que suas queries estejam corretas. O Kanel automatiza isso, permitindo gerar tipos TypeScript que já vêm prontos com a interface de banco de dados do Kysely. Adeus aos erros de digitação nas suas queries SQL!
2. Validação Blindada: TypeScript + Zod
Nunca confie no input do usuário. Nunca! Se você precisa validar dados antes que eles cheguem no banco, o Kanel pode gerar simultaneamente os seus tipos TypeScript e os esquemas de validação do Zod. Isso garante que a sua validação no código esteja sempre e automaticamente 100% sincronizada com as regras e restrições das suas tabelas do PostgreSQL.
3. Apenas a Documentação (Markdown Only)
Às vezes você não precisa de código. Talvez você só queira que os analistas de dados, PMs, ou novas IAs da equipe entendam o esquema do banco sem precisar abrir um cliente SQL. Nesse caso, você pode configurar o Kanel para não gerar TypeScript, gerando apenas a documentação em arquivos Markdown usando o MarkdownGenerator. É o jeito mais fácil de manter sua documentação do banco de dados eternamente atualizada.
Resumo da Ópera
Se você usa PostgreSQL e está cansado de ser o “sincronizador humano” de tipos TypeScript, dê uma chance ao Kanel. Ele automatiza o tédio, previne bugs de esquecimento e te deixa focar na arquitetura que realmente importa.
(Dica: Se quiser iniciar a instalação do zero, os guias oficiais do Kanel possuem um “Quick Start” passo-a-passo mostrando como instalar as dependências via linha de comando!)
Agora é o modo IA como copiloto para deixar este artigo mais rico, com perguntas e respostas (assim você não queima tanto os seus tokens):
Perguntas e respostas sobre o Kanel
Como funciona o sistema de ganchos (hooks) no Kanel?
O sistema de ganchos (hooks) no Kanel é o mecanismo central que torna o framework altamente extensível. Ele funciona como uma forma de interceptar e expandir o processo de geração de código, permitindo que você adapte o resultado final às necessidades do seu projeto.
Na configuração principal do Kanel, esse sistema é dividido essencialmente em duas etapas onde você pode plugar as suas customizações: os preRenderHooks (ganchos executados antes da renderização do código) e os postRenderHooks (ganchos executados após a renderização).
Como eles são usados na prática? É exatamente através desses ganchos que o Kanel consegue se integrar perfeitamente com ferramentas populares do ecossistema, como Kysely, Zod e Knex.
Como mostrei nos exemplos de código da nossa conversa anterior (utilizando meus conhecimentos externos para ilustrar o arquivo .kanelrc.js), você costuma importar uma extensão oficial — como o kanel-zod ou kanel-kysely — e passá-la para o seu array de preRenderHooks.
Quando você roda o gerador, os hooks “pegam carona” nos metadados que o Kanel extraiu do PostgreSQL e geram artefatos extras simultaneamente. É assim que, a partir de uma única leitura do banco, você consegue gerar os tipos em TypeScript e, graças aos hooks, também obter interfaces prontas para o seu banco de dados (Kysely) ou esquemas de validação (Zod) de forma totalmente automatizada.
Como usar o MarkdownGenerator para documentar meu banco?
O MarkdownGenerator é um dos geradores centrais que fazem parte da arquitetura plugável do Kanel v4. Ele tem como objetivo inspecionar o seu banco de dados e criar uma documentação que seja fácil de ler tanto para humanos quanto para LLMs (modelos de linguagem de Inteligência Artificial).
Você pode usá-lo no cenário que o Kanel classifica como “Apenas Documentação” (Documentation Only). Isso significa que você pode configurar o framework para gerar exclusivamente os arquivos em Markdown, ignorando completamente a geração de tipos TypeScript.
A função responsável por inicializar essa geração de documentação é a makeMarkdownGenerator.
Como as fontes mencionam a configuração em JavaScript mas omitem o trecho exato de código, vou utilizar meus conhecimentos externos (assim como fiz nos exemplos anteriores) para te mostrar como essa configuração funciona na prática:
// .kanelrc.js (Exemplo baseado em conhecimento externo)
const { makeMarkdownGenerator } = require('kanel'); // Função citada nas fontes
module.exports = {
connection: process.env.DATABASE_URL,
outputPath: './docs/database', // A pasta onde os arquivos .md serão salvos
// Ao invés de usar o PgTsGenerator (padrão), você instrui o Kanel
// a usar apenas o gerador de Markdown
generators: [
makeMarkdownGenerator()
],
};
Ao executar o Kanel com essa configuração, ele vai se conectar ao seu PostgreSQL e transformar todas as informações do seu esquema (tabelas, colunas, relações) em arquivos .md estruturados. É uma excelente forma de manter a documentação do seu projeto sempre em sincronia com o estado real do banco de dados, sem precisar escrevê-la manualmente.
Posso criar um gerador para outras linguagens?
Sim, você definitivamente pode!
A arquitetura da versão 4 do Kanel foi construída em torno de um sistema de geradores plugáveis. Além dos geradores integrados (como os que vimos anteriormente para TypeScript e Markdown), a ferramenta é projetada para ser totalmente flexível, permitindo que você escreva geradores customizados para qualquer linguagem ou formato.
Isso significa que você pode criar os seus próprios geradores para linguagens e padrões como Python, Rust, GraphQL, ou qualquer outra tecnologia que a sua stack exija. Dessa forma, o seu banco de dados PostgreSQL continua atuando como a única fonte da verdade para o seu esquema, e você pode espelhar essa estrutura automaticamente em diversas linguagens de programação no seu projeto.
Por que o MarkdownGenerator é amigável para LLMs?
As fontes oficiais do Kanel afirmam explicitamente que o MarkdownGenerator é focado em gerar documentação que é amigável tanto para humanos quanto para LLMs. O framework permite que você rode esse gerador no modo “Apenas Documentação” (Documentation Only), extraindo o esquema do PostgreSQL diretamente para arquivos Markdown sem precisar gerar código TypeScript.
No entanto, as fontes não entram nos detalhes técnicos exatos do porquê esse formato ser o ideal para a Inteligência Artificial. Utilizando meus conhecimentos externos (que não estão nas fontes fornecidas, portanto, você pode querer verificá-los independentemente), posso te explicar os motivos práticos que tornam o Markdown tão eficiente para IAs:
- Estrutura Semântica e Clara: O Markdown organiza a informação usando texto puro com marcações simples para cabeçalhos, listas e tabelas. LLMs são treinados massivamente com dados nesse formato e conseguem entender perfeitamente a hierarquia de um banco de dados (como Tabelas > Colunas > Tipos de Dados > Chaves Estrangeiras) quando ela é estruturada assim.
- Economia de Tokens (Context Window): Arquivos Markdown são extremamente leves e não possuem o “ruído” de marcação de outros formatos (como HTML, JSONs muito aninhados ou PDFs). Isso significa que você pode passar o esquema inteiro do seu banco de dados como contexto para a IA gastando muito menos “tokens”, liberando espaço para a IA processar o resto do seu prompt.
- Prevenção de Alucinações de Código: Ao fornecer um arquivo
.mdgerado automaticamente pelo Kanel, você entrega as regras exatas do seu banco de dados para o LLM. Quando você pedir para o ChatGPT ou o GitHub Copilot criar uma query complexa, eles usarão os nomes exatos de colunas e relações presentes no Markdown, evitando que a IA “invente” tabelas que não existem.
Em suma, como o Kanel mantém o PostgreSQL como a única fonte da verdade, usar o MarkdownGenerator para criar a documentação é o fluxo de trabalho perfeito para garantir que qualquer ferramenta de IA que você use sempre tenha o contexto mais atualizado e otimizado possível da sua arquitetura de dados.
Posso gerar tipos para funções e rotinas do PostgreSQL?
Sim, o Kanel possui suporte para extrair informações de funções e rotinas do PostgreSQL.
De acordo com a estrutura da documentação do framework, dentro das configurações do gerador principal de TypeScript (PgTsGenerator), existe uma funcionalidade ou método específico chamado getRoutineMetadata.
Isso indica que você pode configurar o Kanel para inspecionar as rotinas (que no universo do PostgreSQL englobam funções e stored procedures) do seu banco de dados e mapear os metadados delas durante a etapa de geração de código.
Embora as fontes fornecidas não detalhem o código exato de como aplicar essa configuração na prática, você pode encontrar os detalhes de implementação consultando especificamente a seção getRoutineMetadata dentro de PgTsGenerator na documentação oficial.
Onde encontrar o diretório de exemplos no GitHub?
As fontes fornecidas mencionam que você deve consultar o “diretório de exemplos” (examples directory) para ver as configurações completas, mas elas não fornecem o link direto ou a localização exata desse diretório no GitHub.
No entanto, utilizando meus conhecimentos externos (que não estão presentes nas fontes e que você pode querer verificar independentemente), o projeto Kanel é mantido pelo desenvolvedor Kristian Dupont (cujo nome aparece nos direitos autorais da documentação). Você pode encontrar o diretório pesquisando pelo repositório oficial no GitHub, que fica em github.com/kristiandupont/kanel. Dentro do repositório, basta acessar a pasta examples/ na raiz do projeto para encontrar todos os códigos e cenários práticos de configuração que discutimos anteriormente.
O que são Branded IDs no TypeScript?
As fontes mencionam que um dos grandes motivos para usar o Kanel é a sua segurança de tipos (type safety), que inclui a geração de tipos TypeScript precisos utilizando branded IDs. No entanto, o material não detalha o que esse conceito significa na prática.
Utilizando meus conhecimentos externos (que não estão nas fontes e que você pode querer verificar de forma independente), posso te explicar como isso funciona e por que é tão útil:
No TypeScript padrão, a tipagem é estrutural. Isso significa que se o ID de um Usuario no seu banco for do tipo number e o ID de um Pedido também for um number, o TypeScript não vê diferença entre eles. Se você passar o ID de um Pedido para uma função que deleta um Usuário, o TypeScript vai aceitar silenciosamente porque, para ele, ambos são apenas “números”. Isso pode causar bugs catastróficos.
Os Branded IDs (IDs marcados ou tipagem nominal) resolvem isso criando uma “marca” ou “etiqueta” invisível em cima do tipo básico.
Na prática, o código gerado faz algo parecido com isto:
type UsuarioId = number & { __brand: 'UsuarioId' };
type PedidoId = number & { __brand: 'PedidoId' };
Com essa abordagem:
- Em tempo de execução (no JavaScript), eles continuam sendo números normais.
- No momento de compilar, o TypeScript passa a tratar
UsuarioIdePedidoIdcomo tipos completamente diferentes e incompatíveis.
Ao gerar os seus tipos com branded IDs automaticamente do PostgreSQL, o Kanel garante que você nunca vai conseguir cruzar dados acidentalmente. Se uma tabela espera a chave estrangeira de um usuário, você será obrigado a passar um UsuarioId válido, e o seu código se torna muito mais blindado contra erros humanos.
Quais metadados o PgTsGenerator consegue extrair?
De acordo com a estrutura da documentação fornecida, o PgTsGenerator (o gerador principal focado em criar tipos TypeScript) possui métodos dedicados para extrair diferentes níveis de metadados diretamente do seu banco de dados PostgreSQL.
Os métodos de extração de metadados listados para ele são:
- Metadados Gerais (
getMetadata): Utilizado para extrair as informações gerais da estrutura inspecionada. - Metadados de Propriedades (
getPropertyMetadata): Focado em extrair as informações e características detalhadas de propriedades/colunas específicas. - Metadados de Rotinas (
getRoutineMetadata): Como conversamos na sua pergunta anterior, este é usado especificamente para capturar metadados de funções e stored procedures do banco.
É através dessa inspeção e da extração contínua desses metadados que o Kanel consegue mapear com precisão informações vitais do banco, como a nulabilidade das colunas e os relacionamentos entre as tabelas. Além disso, esses metadados alimentam outras funções do próprio gerador, como a generateIdentifierType, que é a responsável por criar aqueles identificadores seguros (branded IDs) sobre os quais também falamos.
Como o PgTsGenerator lida com colunas nulas?
O PgTsGenerator lida com colunas nulas garantindo a segurança de tipos (type safety) ao gerar tipos TypeScript precisos que refletem a nulabilidade exata configurada no seu esquema.
Como o Kanel funciona inspecionando o banco de dados PostgreSQL “ao vivo”, o gerador lê diretamente as regras da sua tabela. Para mapear isso para o TypeScript, o PgTsGenerator utiliza métodos de extração, como o getPropertyMetadata, que captura as características e detalhes de propriedades/colunas específicas. Dessa forma, se uma coluna for definida como capaz de receber valores nulos no PostgreSQL, o código gerado refletirá essa mesma permissão, mantendo o banco como a única fonte da verdade.
Como o Kanel mapeia chaves estrangeiras e relações entre tabelas?
O Kanel mapeia as relações entre tabelas e chaves estrangeiras inspecionando o seu banco de dados PostgreSQL “ao vivo”. Como ele utiliza o banco de dados como a sua única fonte da verdade, o framework consegue ler a estrutura do esquema e gerar tipos TypeScript precisos que já incluem o mapeamento dessas relações de forma automática.
Para que isso aconteça, ele utiliza o seu sistema de geradores (como o PgTsGenerator), que conta com métodos para extrair informações detalhadas do banco, como o getPropertyMetadata.
Utilizando meus conhecimentos externos (que não estão nas fontes fornecidas, portanto, você pode querer verificar de forma independente), posso detalhar como isso se traduz no código TypeScript gerado: na prática, o Kanel mapeia as chaves estrangeiras fazendo uso dos Branded IDs (sobre os quais conversamos anteriormente).
Por exemplo, se a sua tabela de pedidos possui uma chave estrangeira apontando para a tabela de usuarios, o Kanel não vai tipar essa coluna de chave estrangeira apenas como um number genérico. Em vez disso, ele vai usar o tipo nominal exato da tabela referenciada (ex: UsuarioId). Isso garante uma segurança de tipos (type safety) extremamente estrita, impedindo que você passe acidentalmente um ID de uma tabela diferente onde o código espera uma chave estrangeira específica.
Quais os benefícios de tratar código gerado como código nativo?
De acordo com as fontes, um dos motivos para se utilizar o Kanel é justamente o aprimoramento do fluxo de trabalho do desenvolvedor (developer workflow), que encoraja você a fazer o commit do código gerado no Git e tratá-lo como parte integrante da sua base de código.
Como o material fornecido cita essa prática mas não se aprofunda nos detalhes técnicos de suas vantagens, utilizando meus conhecimentos externos (que não estão nas fontes e que você pode querer verificar de forma independente), posso explicar os principais benefícios de tratar o código gerado como nativo:
- Rastreabilidade e Code Review: Ao comitar as interfaces TypeScript, documentações em Markdown ou esquemas do Zod gerados, as mudanças na estrutura do seu banco de dados se tornam alterações de código visíveis no seu Pull Request. Isso permite que toda a equipe revise exatamente como a adição ou modificação de uma coluna afetará a aplicação.
- Independência de Build e CI/CD: Com os arquivos já salvos no repositório, a sua esteira de integração contínua (CI), ferramentas de deploy e até mesmo outros desenvolvedores não precisam de uma conexão ativa com o seu PostgreSQL “ao vivo” apenas para conseguir compilar o projeto ou executar testes.
- Sincronia Perfeita Histórica: Como vimos em exemplos anteriores, esse fluxo garante que cada commit e cada branch no Git carregue consigo a representação exata dos tipos que o banco de dados possuía naquele ponto específico no tempo, evitando assincronias graves ao navegar pelo histórico do projeto.
- Transparência e Previsibilidade: O código deixa de ser um artefato “mágico” gerado debaixo dos panos. Como ele vive nas suas pastas (ex:
src/db/generated), você e sua IDE sabem exatamente onde ele está, o que facilita a inspeção manual, o autocompletar eficiente e o fornecimento de contexto claro para assistentes de Inteligência Artificial.
Posso automatizar o Kanel na minha esteira de CI/CD?
O fluxo de trabalho recomendado oficialmente pelo Kanel muda um pouco a dinâmica de como você precisaria utilizá-lo na sua esteira de CI/CD. Em vez de exigir que a ferramenta rode na nuvem durante o deploy, a documentação orienta explicitamente que você faça o commit do código gerado no Git e o trate como parte integrante da sua base de código.
Como conversamos na sua pergunta anterior, isso traz o grande benefício da independência de Build e CI/CD. Como os arquivos (sejam eles tipos TypeScript, esquemas Zod ou documentação Markdown) já estão salvos no repositório do projeto, a sua esteira não precisa baixar o Kanel ou se conectar a um banco de dados PostgreSQL “ao vivo” apenas para compilar a aplicação ou rodar os seus testes automatizados.
No entanto, utilizando meus conhecimentos externos (que não estão presentes nas fontes e que você pode querer verificar de forma independente), se o seu objetivo é garantir que a equipe nunca esqueça de atualizar os tipos, você definitivamente pode automatizar o Kanel na sua esteira como uma etapa de validação.
O fluxo comum para automatizar isso no CI/CD (como no GitHub Actions ou GitLab CI) funciona assim:
- A esteira sobe um banco PostgreSQL temporário (usando serviços ou contêineres Docker).
- A esteira roda as migrações do seu projeto para criar as tabelas nesse banco vazio.
- A esteira executa o Kanel conectando-se a esse banco temporário.
- Por fim, ela roda um comando para checar se houve alterações nos arquivos (como um
git diff). Se o Kanel gerar arquivos diferentes dos que estão no repositório, a esteira falha o Pull Request, avisando ao desenvolvedor que ele alterou o banco mas esqueceu de rodar o Kanel e comitar os novos tipos!
Dessa forma, você mantém o código no repositório (conforme a recomendação oficial do framework), mas usa o CI/CD para garantir que o seu banco de dados e os seus tipos TypeScript nunca fiquem fora de sincronia.
Quais as principais diferenças entre Kanel e um ORM tradicional?
A principal diferença entre o Kanel e um ORM tradicional é que o Kanel atua como um “ORM reverso”.
Essa diferença fundamental se desdobra nos seguintes pontos:
- A Fonte da Verdade: Em um ORM tradicional (como pontuei utilizando meus conhecimentos externos na nossa primeira conversa), você geralmente escreve seus modelos na linguagem de programação (ex: classes em TypeScript) e usa esses modelos para gerar tabelas no banco através de migrações. No Kanel, a lógica é invertida: o seu banco de dados PostgreSQL é a única fonte da verdade. É o esquema estruturado no banco que dita quais serão os seus tipos, e não o contrário.
- Geração de Código vs. Abstração Pesada: Enquanto os ORMs tradicionais costumam fornecer uma camada complexa e “mágica” para você consultar e manipular dados em tempo de execução, o Kanel é estritamente um framework de geração de código. Ele inspeciona o seu banco de dados ao vivo e produz os arquivos estáticos para o seu projeto, os quais você deve fazer o commit no controle de versão (Git) e tratar como parte nativa da sua base de código.
- Integração Modular: Em vez de forçar você a usar uma linguagem de query proprietária do próprio ORM, a arquitetura de geradores plugáveis do Kanel se concentra em gerar os tipos perfeitos para alimentar outras ferramentas que você já usa. Ele gera automaticamente as interfaces precisas para query builders focados em segurança de tipos, como o Kysely, ou esquemas de validação de dados, como o Zod.
Em resumo, enquanto o ORM tradicional tenta abstrair o banco de dados escondendo-o atrás do código da aplicação, o Kanel coloca o PostgreSQL no centro do palco, extraindo as regras reais de lá para garantir que o seu código TypeScript esteja sempre 100% correto e sincronizado.
Como personalizar nomes de tabelas para evitar conflitos de schema?
As fontes fornecidas citam a existência de métodos do PgTsGenerator (como o getMetadata e generateIdentifierType) e o uso do sistema de ganchos (hooks), mas não trazem o passo a passo exato de código para lidar com a customização de nomes no cenário de múltiplos schemas.
Portanto, utilizando meus conhecimentos externos (que não estão presentes no material fornecido e que você pode querer verificar de forma independente na documentação oficial), vou te mostrar como os desenvolvedores costumam resolver a colisão de nomes na prática.
A maneira mais robusta de personalizar os nomes das tabelas geradas (para que users do schema public não atropele users do schema auth) é sobrescrevendo a forma como o Kanel extrai e gera os metadados através da função getMetadata.
Você pode fazer isso diretamente no seu arquivo de configuração (.kanelrc.js), interceptando o nome original e adicionando um prefixo com base no schema ao qual a tabela pertence. Fica mais ou menos assim:
// .kanelrc.js (Exemplo baseado em conhecimento externo)
const { defaultGetMetadata } = require('kanel');
module.exports = {
connection: process.env.DATABASE_URL,
outputPath: './src/db/generated',
// Mapeando os dois schemas problemáticos
schemas: ['public', 'auth'],
// Sobrescrevendo a configuração do PgTsGenerator
getMetadata: (details, generateFor, inst) => {
// 1. Pegamos os metadados originais que o Kanel geraria normalmente
const metadata = defaultGetMetadata(details, generateFor, inst);
// 2. Se a tabela não for do schema público, nós injetamos o nome do schema como prefixo
if (details.schemaName !== 'public') {
// Ex: Uma tabela 'users' no schema 'auth' vira 'AuthUsers'
const prefix = details.schemaName.charAt(0).toUpperCase() + details.schemaName.slice(1);
metadata.name = `${prefix}${metadata.name}`;
}
// 3. Devolvemos os metadados modificados para o gerador
return metadata;
},
};
Por que isso é tão poderoso? Porque ao interceptar a geração logo na etapa do getMetadata (que é um dos pilares do PgTsGenerator listados nas fontes), você não está apenas mudando o nome do arquivo final. Você está dizendo ao Kanel para tratar aquela entidade inteira com o novo nome.
Isso significa que as chaves estrangeiras, as relações e até os geradores adicionais (como os hooks do Zod ou Kysely) vão respeitar esse novo nome automaticamente. Assim, você mantém a paz no seu código, a segurança de tipos intacta e o compilador do TypeScript feliz!
📚 Continue Aprendendo
Se você gostou deste artigo sobre arquitetura de dados e automação, vai destravar novos níveis de eficiência com estes guias práticos do ecossistema de desenvolvimento:
Domine a integração profunda entre o backend e suas rotinas de banco de dados estruturadas.
Aprenda a conectar sistemas externos e criar fluxos automatizados robustos orientados a eventos.
Mantenha a integridade e a performance da sua interface ao lidar com arquiteturas distribuídas.
Explore o desenvolvimento ponta a ponta unindo software moderno e interfaces físicas interativas.
