Pitch: Criei uma CLI para gerenciar bancos locais que bateu 530 downloads no NPM em 3 dias (e explico a arquitetura por trás) · eduwz

Fala pessoal do TabNews! Tudo bem?

Sabe aquela dor de cabeça diária que todo desenvolvedor backend tem ao manipular bancos de dados locais? Fazer backup, dropar, restaurar, checar tamanhos e limpar instâncias pesadas para "resetar" o ambiente... Ter que lembrar de cabeça as flags do pg_dump, pg_restore ou escrever scripts bash frágeis era uma tarefa repetitiva e propensa a erros para mim.

Foi exatamente para resolver a "minha" dor que construí e publiquei o Herdux CLI (uma ferramenta focada na Developer Experience para gerenciar "manadas" de bancos de dados via terminal).

Nos primeiros quatro dias de vida, a versão inicial suportava apenas PostgreSQL e bateu mais de 530 downloads orgânicos no NPM. Isso me provou que essa não era uma dor só minha.

Hoje estou lançando oficialmente a versão 0.4.2, que transforma o projeto num verdadeiro "Canivete Suíço" para infraestrutura local, suportando múltiplas engines (hoje PostgreSQL e MySQL).

O que é o Herdux CLI na prática?

Ao invés de decorar scripts exóticos e misturar binários diferentes, você gerencia tudo com uma interface unificada e segura. Funciona assim:

# PostgreSQL (Engine Padrão)
hdx backup mydb --drop --yes      # Faz backup e dropa o banco em um único comando
hdx restore ./backups/mydb.dump   # Restaura criando o banco automaticamente se faltar

# Agora com suporte 100% nativo a MySQL
hdx --engine mysql list --size    # Lista todos os bancos do MySQL ordenados por tamanho
hdx --engine mysql clean          # Abre uma interface interativa (multi-seleção) para batch-drop seguro

Mesmos comandos. Qualquer engine. Zero fadiga de terminal.

A Engenharia por trás (O Pulo do Gato)

Expandir do PostgreSQL para escalar o MySQL (e futuramente Redis e SQL Server) exigia uma fundação sólida. Como manter o código limpo sem lotar a CLI de IFs e Switches?

Eu separei rigorosamente o projeto usando uma Arquitetura Multi-Engine (Design Pattern: Factory & Strategy). No núcleo, os arquivos de comando (src/commands/) não sabem absolutamente nada sobre banco de dados. Eles apenas coletam os inputs do usuário. Quem faz o trabalho real (invocar o psql, o mysqldump, tratar erros) são as implementações específicas que ficam isoladas dentro da pasta infra/engines/.

O Engine Factory detecta a intenção do usuário via profile salvo no ~/.herdux/config.json ou flag na CLI, e injeta a engine correta em tempo de execução.

Estabilidade Tripla: Unitários, Integração e E2E no Docker

Ferramentas CLI que manipulam e deletam bancos de dados são "facas afiadas". Para o projeto ser confiável, a cobertura de código precisava ser do "Padrão Ouro":

Testes Unitários: Testam os comandos e infraestrutura isolados (via Mocks do Jest) garantindo as regras de negócio em microssegundos.
Nova Camada de Integração CLI (Headless): Como o Herdux é interativo (usa prompts), criei um Test Harness customizado com execa. Nossos testes enganam o Node forjando um ambiente TTY falso (HERDUX_TEST_FORCE_TTY) e injetam diretórios de configuração virtuais. Assim, conseguimos provar matematicamente pelo Jest que se você digitar uma flag no terminal, os menus interativos são exibidos ou contornados perfeitamente.
E2E com Contêineres Efêmeros: Sempre que um PR é aberto, o GitHub Actions sobe instâncias reais em Docker (um container PostgreSQL, um container MySQL). O fluxo E2E invoca a CLI crua, que se conecta nas portas do Docker, cria bancos, popula, extrai dumps em disco (testando os binários nativos do SO hospedeiro) e por fim, o Action executa um teardown automático apagando tudo.

Se não estiver verde nesses 3 lugares, não vai pra master. Ponto.

O Futuro é Open Source

O Herdux está com a casa arrumada (CONTRIBUTING.md, Code of Conduct, PULL_REQUEST_TEMPLATE e até regras dedicadas para contribuições via AIs no AGENTS.md e em docs/VISION.md). Tudo lapidado para garantir a melhor entrada para a comunidade.

Se você também gerencia instâncias locais no seu desenvolvimento diário, aposente seus scripts! Testa lá e me diga o que achou. O código é 100% open-source e Issues, PRs e Estrelinhas são super bem-vindas. ⭐

NPM: https://www.npmjs.com/package/herdux-cli
GitHub: https://github.com/herdux/herdux-cli

Ficaria honrado de receber o feedback de vocês, seja sobre a usabilidade da CLI no dia-a-dia, seja sobre a arquitetura do código lá no repositório. O que acharam dessa abordagem arquitetural e das camadas de teste?