Pitch: Estou construindo o depx: algumas escolhas que fiz e o problema que quero resolver · OhMyDoc

Faz um tempo que eu estou tentando encontrar um projeto open-source em que realmente valha a pena investir energia.

Nesse processo eu tive várias ideias, descartei algumas, mudei de direção outras vezes e percebi uma coisa: eu estava procurando demais por “uma grande ideia” quando talvez fosse melhor começar por um problema pequeno, concreto e que eu mesmo gostaria de ter uma ferramenta melhor para resolver.

Foi daí que nasceu o depx.

GitHub: https://github.com/ruidosujeira/depx

A ideia começou olhando para uma coisa meio banal: dependências.

A gente instala dezenas, às vezes centenas ou milhares delas, mas depois de um tempo o package.json e principalmente o lockfile viram quase uma caixa-preta.

Você sabe que um pacote está ali.

Mas por quê?

Quem depende dele?
Meu código realmente usa essa dependência?
Existem versões duplicadas?
Tem alguma dependência antiga que ficou esquecida?
Uma vulnerabilidade reportada realmente está em uma parte relevante da árvore ou é só mais uma linha no meio de um relatório enorme?

Existem ferramentas que respondem partes dessas perguntas muito bem.

O problema que começou a me incomodar é justamente esse: são partes.

Então decidi que o depx não deveria ser simplesmente mais um comando para imprimir uma árvore de dependências.

Quero que ele seja uma ferramenta para entender o estado das dependências de um projeto.

Algumas escolhas que fiz no caminho

Uma das primeiras decisões foi não tentar substituir npm, pnpm, Cargo ou qualquer outro package manager.

Isso seria um projeto completamente diferente e, sinceramente, não acho que seja onde está o problema mais interessante.

Os package managers já sabem instalar pacotes.

O que eu quero explorar é o que acontece depois que eles foram instalados.

Por isso o depx trabalha em cima das informações que já existem no projeto, como:

código-fonte;
manifests;
lockfiles;
grafo de dependências.

Outra escolha foi manter a ferramenta local.

Não quero que seja necessário enviar o código de um projeto para um serviço externo apenas para entender suas dependências.

A experiência que eu quero é mais próxima disso:

depx analyze

E alguns segundos depois você começa a entender o que está acontecendo naquele projeto.

Também escolhi escrever o projeto em Rust.

Não foi simplesmente porque Rust está na moda.

Para uma CLI desse tipo eu gosto bastante da combinação de:

binário único;
desempenho;
previsibilidade;
bom ecossistema para parsing;
boas bibliotecas para construção de ferramentas de desenvolvimento.

Eu não quero que o depx vire uma coleção infinita de checks

Essa foi outra decisão importante.

É muito fácil uma ferramenta dessas começar assim:

verifica isso
verifica aquilo
verifica mais aquilo outro

E eventualmente perder qualquer identidade.

Estou tentando manter uma pergunta no centro do projeto:

Por que essas dependências estão aqui e qual é a relação delas com o meu código?

A partir disso fazem sentido coisas como:

depx analyze

para analisar as dependências do projeto.

depx why <pacote>

para entender por que determinada dependência existe na árvore.

depx duplicates

para encontrar versões duplicadas.

depx audit

para analisar vulnerabilidades com mais contexto.

Mas eu não quero adicionar comandos apenas para aumentar a lista de features.

Eles precisam fazer parte da mesma história.

E não, eu não quero colocar IA nisso

Outra decisão deliberada foi essa.

Não tenho interesse em colocar um chatbot dentro do depx ou adicionar alguma funcionalidade com LLM simplesmente para poder escrever AI-powered no README.

Se algum problema pode ser resolvido analisando o código, o lockfile e o grafo de dependências de maneira determinística, prefiro resolver dessa forma.

Para esse projeto, previsibilidade é uma característica importante.

Eu quero conseguir mostrar por que o depx chegou a determinada conclusão.

Algo próximo de:

my-app
└── package-a
    └── package-b
        └── vulnerable-package

em vez de simplesmente:

Vulnerability found.

A ideia é transformar informação de dependência em algo que o desenvolvedor consiga realmente investigar.

O projeto ainda está amadurecendo

Também não quero vender a ideia como se eu tivesse resolvido dependency management.

Não resolvi.

O depx ainda é um projeto relativamente novo e provavelmente algumas das decisões atuais vão mudar bastante conforme ele for usado em projetos reais.

Inclusive é justamente por isso que estou escrevendo aqui.

Neste momento, feedback vale muito mais para mim do que stars.

Principalmente de quem trabalha com:

projetos com árvores de dependências grandes;
monorepos;
dependências transitivas estranhas;
projetos antigos;
aquele package.json que ninguém tem coragem de limpar porque existe sempre o medo de quebrar alguma coisa misteriosa em produção.

Quero descobrir onde o depx realmente ajuda e, principalmente, onde ele ainda é inútil.

Se a ideia fizer sentido para você, dá uma olhada:

GitHub: ruidosujeira/depx

Issues, críticas, casos estranhos e sugestões são muito bem-vindos.

Prefiro descobrir agora que alguma premissa está errada do que passar meses construindo em cima dela.

E se você já passou pela situação de olhar para uma dependência e pensar:

“por que diabos isso está instalado?”

eu adoraria conhecer o caso.