stamatios
← Voltar ao feed
Parede modular de peças de ferramentas encaixáveis, metáfora de devtools plugáveis e extensíveis para frameworks web
Dev & Engenharia

Proposta de devtools modulares e plugáveis para a era agêntica

resumo de ~3 min

O problema: DevTools que reinventam a mesma infraestrutura

Anthony Fu e colaboradores apresentam o Devframe, um framework para construir DevTools de forma modular, extensível e portável entre frameworks. A motivação vem de anos construindo ferramentas como UnoCSS Inspector, Vite Plugin Inspect, Vitest UI, Nuxt DevTools, ESLint Config Inspector e Node Modules Inspector. Todas compartilham o mesmo objetivo essencial - tornar visível o estado implícito do desenvolvimento - e, apesar disso, cada uma acaba reconstruindo isoladamente a mesma infraestrutura: RPC, sincronização de estado, serialização, hospedagem de assets e interface web. No ecossistema, frameworks e build tools criam DevTools próprios com capacidades sobrepostas (inspetores de dados, visualizadores de assets, analisadores de build, terminais), mas presos às particularidades de cada servidor de desenvolvimento.

A visão de um ecossistema universal

A ideia, esboçada desde 2023 em artigos sobre o Nuxt DevTools, propõe libertar os DevTools dessas fronteiras: se cada capacidade fosse reutilizável e modular, comunidades poderiam colaborar em uma única ferramenta em vez de espalhar o trabalho por várias versões da mesma ideia. O esboço era aspiracional, e encontrar o limite certo de abstração foi a parte difícil. O trabalho migrou do Nuxt DevTools para o Vite DevTools (desenvolvido na Vercel), que deu um lar concreto para provar a experiência, sempre com o objetivo de abrir para outros toolchains. LLMs aceleraram a exploração e validação do design, até surgir o Devframe.

Como funciona: uma definição, um handler padrão, muitos adaptadores

O Devframe é descrito como um framework para construir DevTools, análogo ao que Nuxt ou Next.js representam para aplicações web, e, na camada de adaptadores, análogo ao unplugin para plugins de bundler. Uma "devframe" é definida com defineDevframe(), descrevendo identidade, capacidades, funções RPC, estado compartilhado, SPA, diagnósticos e interface para agentes de código. Com initDevframe(), essa definição vira uma instância viva que expõe um handler no padrão Web Standard (Request → Response) e também um middleware no estilo Connect para Node. Esse handler é a fronteira da ferramenta: atrás dele ficam SPA, metadados de conexão, RPC ao vivo, autenticação e um endpoint MCP opcional.

Como frameworks modernos já convergem para esse tipo de fronteira (Hono e Nitro aceitam requests Web Standard; Next.js e SvelteKit expõem route handlers; Vite e Rsbuild aceitam middleware Connect), a mesma devframe pode ser montada em quase qualquer host. Adaptadores de nível superior empacotam a mesma definição como CLI standalone, servidor de desenvolvimento dedicado, plugin do Vite DevTools, servidor MCP ou relatório estático - um mesmo pacote pode oferecer vários desses pontos de entrada. O modelo já é usado em Node Modules Inspector, ESLint Config Inspector e Vite Plugin Inspect. No lado do navegador, cada ferramenta escolhe livremente o framework de UI: os devframes embutidos usam Vue, Svelte, Solid, React e Next.js justamente para validar essa promessa.

Interfaces visuais e para agentes de código

Cada devframe pode parear seu painel visual com uma interface estruturada para agentes de código. Visualizações servem para exploração e comparação; agentes podem buscar contexto focado, correlacioná-lo com o código e executar ações em múltiplas etapas - a fonte de verdade é a mesma. As funções RPC permanecem privadas por padrão e precisam ser explicitamente expostas ao agente; o adaptador MCP as traduz com descrições, schemas e metadados de segurança. O Devframe também integra o json-render da Vercel, que descreve UI como dados serializáveis de um catálogo limitado de componentes, facilitando que agentes gerem dashboards previsíveis e permitindo UI fornecida pelo lado do servidor com renderizador agnóstico. A equipe admite que ainda explora descoberta, permissões e o equilíbrio entre os dois fluxos.

Devframes embutidos

Para provar a abstração, são distribuídos devframes de exemplo: o Data Inspector (Vue) permite explorar objetos do lado do servidor com Jora e inspecionar JSON ou processos Node em execução; o Terminals (Svelte) oferece terminal no navegador, com saída somente leitura ou sessões PTY interativas - inclusive para rodar agentes como Claude Code a partir do navegador; o Accessibility Inspector (Solid) usa axe-core para listar violações WCAG e pode convertê-las em prompts de correção para agentes. Outros cobrem editor VS Code na web, gestão de assets, painel Git, previews de Open Graph e o próprio inspetor de RPC/estado do Devframe.

Do devframe ao host de DevTools

Com várias ferramentas ativas, surge o problema de descoberta: consoles cheios de URLs e apps com botões flutuantes desconexos. O hub (@devframes/hub) é uma camada de composição headless onde devframes montados contribuem com docks, comandos, mensagens, terminais e estado compartilhado, aparecendo ao usuário em um único ponto consistente. initHub() coloca tudo atrás de um único handler padrão, com registro RPC, estado, conexão e autenticação compartilhados. Há projetos de referência para Vite, Next.js, Hono, Nitro e Rsbuild.

O Vite DevTools é o primeiro host principal construído sobre essa fundação, e plugins Vite regulares podem contribuir diretamente via uma nova entrada devtools.setup, o que torna a adoção incremental. O Nuxt DevTools v4, previsto para o Nuxt v5 com opção manual no Nuxt 4, é construído sobre Devframe e Vite DevTools, herdando ambos os ecossistemas; o Vue DevTools também migra para essa fundação. Internamente, já existe um protótipo de integração com o Next.js DevTools sem modificações nos plugins.

Conclusão e próximos passos

O Devframe v1.0 estabiliza a interface; o Vite DevTools terá release estável, e Nuxt e Vue continuam validando o modelo. A visão é que uma boa ferramenta possa ser construída uma vez, viajar mais longe e melhorar com contribuições de várias comunidades - infraestrutura compartilhada por baixo, experiências específicas por cima, e capacidades estruturadas para pessoas e agentes de código. A equipe convida contribuições de devframes, experimentos, ideias de design e feedback.