Executando verificação de segurança...
10
Jeffs
2 min de leitura ·

Pitch: Eu cansei de dd() e criei um debugger visual pra PHP que não precisa de Xdebug

Fala, pessoal.

Sou dev PHP há anos e como todo mundo, vivo entre dd(), var_dump() e aquela tentativa semestral de configurar o Xdebug que funciona por 3 dias até o Docker rebuildar e quebrar tudo.

Depois de perder horas demais debugando com echo onde não deveria, resolvi criar o DDLess — um app desktop que faz debugging visual de qualquer projeto PHP sem instalar extensão, sem plugin de IDE, sem Composer, sem alterar uma linha de código.

O que ele faz

Você abre o projeto, define breakpoints clicando na linha, manda uma request, e o DDLess pausa ali. Variáveis, call stack, step in/out/over — tudo visual, como deveria ser.

Mas ele vai além de só debugging. Tem também:

  • Dumppoints — é um dd() visual: você escolhe a linha e as expressões na UI, sem sujar o código. Ele avalia, mostra bonito, e termina a execução.
  • Task Runner — um REPL com contexto do framework. Escreve PHP, roda, vê o output em streaming. Com autocomplete de classes, métodos e helpers do projeto.
  • Method Execution — seleciona qualquer método de qualquer classe e testa direto, com auto-scaffold dos parâmetros.
  • Proxy Mode — intercepta requests do browser seletivamente, sem precisar mudar URL nem usar Postman.
  • CLI Debug — debuga artisan commands, PHPUnit, migrations, queue workers. Roda .ddless/php-ddless 8001 artisan test e os breakpoints funcionam normalmente.
  • Code navigation — Ctrl+Click pra go-to-definition, busca de arquivos e busca de conteúdo no projeto inteiro.

Por que funciona em qualquer lugar

O DDLess não usa socket nem extensão PHP. Ele instrumenta o código em tempo de execução via AST (nikic/PHP-Parser) e usa comunicação baseada em arquivos. Na prática isso significa que funciona em Local, Docker, WSL e SSH remoto sem configuração extra. Se o PHP roda lá, o DDLess debuga lá.

Zero path mapping manual. Zero xdebug.client_host. Zero "funciona na máquina do fulano mas na minha não".

Frameworks

Laravel, WordPress, Symfony, Drupal, CakePHP, Slim, ou qualquer projeto PHP 7.4+. Pra Laravel tem bootstrap automático. Pra outros frameworks, aponta o entry point e pronto.

Roda em

Windows, macOS (Intel e Apple Silicon) e Linux (AppImage, .deb, .rpm).

O projeto é meu, feito de forma independente. Tô usando no dia a dia e está estável.

Se quiserem testar: ddless.com

Qualquer dúvida, feedback ou bug, me chama aqui ou no Discord.

Fonte: https://ddless.com

Carregando publicação patrocinada...
3
luca

Caramba cara que projeto legal! E muito util de fato. Como você desenvolveu isso qual foi processo linguagem e etc. Estou muito interessado para saber, eu sempre vejo a galera aqui desenvolvendo projetos assim e sempre fico curioso sobre o processo.
Muito top parabens pelo projeto e sucesso meu irmão! Se for possível falar sobre como aconteceu esse desenvolvimento e o que você usou vou agradecer dms.

1
Jeffs
  • Autor
    Autor

Obrigado pelo comentário! Então, eu uso Windows com WSL e é uma dor utilizar o Xdebug nesse setup. Toda vez que preciso remontar o container, tenho que configurar tudo de novo. O Xdebug funciona muito bem quando está tudo na sua máquina local e estável, mas quando falamos de containers a história muda completamente.

Além disso, debugar algo não é apenas colocar breakpoints e ver valores de variáveis — ainda mais em 2026. Precisamos pensar fora da caixa e usar todas as ferramentas ao nosso alcance, como IA. Foi com essa mentalidade que desenvolvi o DDLess: primeiro para ajudar quem tem dificuldade com o Xdebug, e segundo para quem já conhece o processo de debug mas quer algo mais simples e poderoso, com ferramentas que vão além do breakpoint tradicional.
O processo de desenvolvimento foi cheio de pivôs. Comecei tentando resolver o debug usando o phpdbg como ponte de comunicação. Mas senti que estava colocando uma barreira no DDLess, porque a pessoa precisava ter o phpdbg instalado no PHP — algo que deveria vir compilado por padrão, mas nem sempre vem. Cada amigo que testava reclamava, cada teste feito eu sentia que o processo era doloroso demais. Foi um retrocesso.

Então pensei: vou usar regex com instrumentação de arquivos. Basicamente, eu copio os arquivos que vão ser debugados, insiro minhas funções globais nas linhas onde o breakpoint deve atuar, e pronto — funciona sem nenhuma dependência. Mas aí veio outro problema: regex é outra dor. O programador PHP escreve a sintaxe de diversas maneiras diferentes e não dá pra esperar que todo mundo siga a PSR. Cada edge case quebrava algo.

Então fui para outro nível: removi o regex e passei a usar AST parsing (nikic/PHP-Parser). Isso matou o problema de vez. Pode parecer um mini compilador, mas é o que garante que a instrumentação funciona independente de como o código foi escrito.

Eu utilizei electronJS, reactjs, php como base da comunicação com o projeto.

Fluxo de Debug:

  1. Dev seta breakpoint → Electron escreve breakpoints.json
  2. Dev envia request → Electron executa PHP com DDLESS_DEBUG_MODE=true
  3. PHP carrega debug.php → instrumenta código via AST
  4. PHP executa → atinge breakpoint → escreve breakpoint_state.json
  5. PHP fica em loop (polling breakpoint_command.json)
  6. Electron detecta breakpoint_state.json (polling 100ms)
  7. UI mostra variáveis, stack, waterfall
  8. Dev clica Continue → Electron escreve breakpoint_command.json
  9. PHP lê comando → retoma execução
4