Validação com check

buildprint check valida os arquivos do seu workspace fragmentado antes de você enviá-los de volta para Bubble. Ele lê os arquivos JSON que você editou, executa o verificador de problemas do Buildprint sobre eles e relata quaisquer problemas - campos obrigatórios ausentes, expressões malformadas, IDs duplicados e outros problemas que produziriam uma gravação inválida ou rejeitada no Bubble.

Verificando arquivos alterados

O caso comum não usa argumentos:

buildprint check

Sem caminhos, check analisa os arquivos que foram alterados desde o último snapshot sincronizado do Bubble e valida apenas esses. Se nada tiver mudado, ele exibe No changed files. No checks run. e encerra.

É isso que você quer quase sempre. Como check delimita a análise às suas alterações, ele não o sobrecarrega com resultados sobre partes do app que você nunca tocou.

Escopo direcionado

check (e apply) operam nos seus arquivos alterados, não no app inteiro. Uma regra só é executada em um arquivo que esteja no escopo - por padrão, seus arquivos alterados ou os alvos explícitos que você informar.

A consequência prática: uma violação do Bubble já existente em uma página que você não tocou não será mostrada. O Buildprint só sinaliza um problema em uma página quando suas edições fazem essa página entrar no escopo. Se você sincronizar um snapshot que já contém, por exemplo, IDs de ação duplicados em uma página, check permanece em silêncio sobre essa página até você editar algo dentro dela. Não existe uma flag para forçar uma varredura do app inteiro.

Para regras que precisam comparar com o estado anterior (por exemplo, detectar uma exclusão definitiva de um tipo de dados ou uma alteração na largura de um contêiner), check também carrega a versão base dos arquivos alterados relevantes a partir do último snapshot sincronizado, para que a comparação seja precisa. Isso acontece automaticamente - você não precisa configurar nada.

Verificando um alvo específico

Você pode apontar check para um arquivo ou diretório explícito em vez do conjunto de arquivos alterados:

buildprint check pages/home/page.json
buildprint check pages/home/elements/card

Um alvo de diretório inclui todos os arquivos abaixo dele. Você pode passar mais de um caminho. Se um alvo não existir no workspace da branch atual, check falha com um erro informando os alvos que não foram correspondidos.

Alvos explícitos geralmente não são necessários. Na maioria dos casos, execute buildprint check sem caminhos - ele verifica apenas os seus arquivos alterados e evita resultados não relacionados. Quando você passar caminhos, check lembra disso no final de uma execução sem problemas.

Lendo a saída

Por padrão, check imprime uma saída legível para humanos:

• Se ele normalizou algum JSON alterado no disco antes da verificação (reescrevendo os arquivos na ordem e no formato canônicos do Buildprint, ou atualizando sidecars de layout), ele lista esses arquivos em um resumo de "Autofixed". Isso é esperado e inofensivo - o Buildprint reescreveu seus arquivos editados manualmente no formato canônico de autoria para que eles não falhem apenas por espaços em branco ou ordem.

• Em seguida, ele lista os problemas, cada um com um nível: error, warning ou info.

• Uma linha de progresso e estatísticas finais mostram quantas verificações foram executadas como clean, info, warning ou error.

Se algum problema for um error, check encerra com código diferente de zero e imprime Check failed: errors present. Warnings e info não bloqueiam. Uma execução limpa nos seus arquivos alterados termina com um lembrete para executar buildprint apply.

Quando uma verificação do app falha com erros de expressão, check também grava um artefato de dicas de busca de schema em .buildprint/outputs/ para ajudar você a encontrar o campo, operador ou mensagem de elemento corretos. O caminho é exibido na saída.

Filtrando a saída

Eleve o nível mínimo reportado para reduzir o ruído:

buildprint check --level warning --json

--level aceita error, warning ou info (padrão info). Níveis abaixo do limite ficam ocultos. --json emite o relatório como JSON em vez de texto legível para humanos - útil para automação ou para alimentar outra ferramenta.

Executando uma única regra

Restrinja a execução a uma regra ou a uma família de regras:

buildprint check --rule canonical-form
buildprint check --rule 'children-manifest/*'

--rule <id> corresponde a um ID exato da regra ou a um glob prefix/* que cobre uma família inteira. Todo o resto é ignorado.

Verificar e aplicar em uma etapa

Para validar e, se não houver erros que bloqueiem, aplicar imediatamente:

buildprint check --auto-apply

--auto-apply executa a verificação completa nos seus arquivos alterados e, somente se a execução não retornar erros, aplica o workspace ao Bubble. Se a verificação encontrar erros, nada é aplicado.

--auto-apply exige o conjunto completo de arquivos alterados e o conjunto completo de regras, então não pode ser combinado com:

• caminhos explícitos

• --rule

• --json

Passar qualquer um desses junto com --auto-apply é um erro de uso.

Flags