- O que 'YAML válido' quer dizer de fato?
- O YAML tem uma gramática rígida: a indentação precisa ser consistente (só espaços, sem tabs), os mapeamentos precisam de dois-pontos seguidos de espaço, as coleções inline (as formas [...] e {...}) precisam estar fechadas, e textos com caracteres especiais precisam de aspas. 'Válido' aqui quer dizer que o documento é lido sem erro pela especificação YAML 1.2 com o esquema de tipos compatível com JSON — o mesmo subconjunto usado por manifestos do Kubernetes, workflows do GitHub Actions e arquivos do Docker Compose. Se é lido aqui, vai ser lido nessas ferramentas.
- Por que o número da linha não bate com o meu editor?
- Deveria bater — mostramos linha e coluna contando a partir de 1, como o VS Code, os editores da JetBrains, o vim e a maioria dos outros. O js-yaml usa posições a partir de 0 internamente; somamos 1 antes de mostrar. Se não bater, confira se o seu editor e o validador estão vendo o mesmo conteúdo (uma quebra de linha no fim ou um BOM no começo podem deslocar uma linha).
- Por que 'yes', 'no', 'on', 'off' são tratados como texto?
- O YAML 1.1 os convertia em booleanos, o que causou o famoso 'problema da Noruega' (o código do país NO sendo lido como o booleano false). O YAML 1.2 — e o JSON_SCHEMA que este validador usa — os mantém como texto simples, igual ao Kubernetes, GitHub Actions, Docker Compose e à maioria dos leitores modernos. Se você quer booleanos, escreva 'true' ou 'false' explicitamente.
- Aceita YAML com vários documentos (separadores ---)?
- Sim. O validador lê o arquivo inteiro e diz quantos documentos encontrou. YAML com vários documentos é comum em manifestos do Kubernetes (cada --- separa um Service, Deployment, ConfigMap etc.). Se qualquer documento for inválido, a validação falha com a linha e a coluna contadas a partir do começo do texto.
- Qual a diferença para um conversor de YAML para JSON?
- A intenção é outra. O conversor supõe que seu YAML é válido e entrega JSON. O validador foca em dizer se ele é válido em primeiro lugar — e, se não for, onde exatamente está o erro. Use o validador quando algo depois (kubectl, GitHub Actions, ansible-playbook) recusar seu arquivo e você precisar achar o problema rápido.
- O leitor pega todo tipo de erro?
- Ele pega todo erro de sintaxe — indentação errada, aspas sem fechar, coleções inline soltas, âncoras inválidas. Ele NÃO pega erros de significado contra um esquema (por exemplo 'este Deployment do Kubernetes está sem um campo obrigatório' ou 'o nome deste passo do GitHub Actions está escrito errado'). Para validar contra um esquema, você precisa do validador da ferramenta de destino (kubectl --dry-run, actionlint etc.).
- E âncoras, referências e textos em várias linhas?
- Totalmente aceitos. Âncoras (&nome) e referências (*nome) são resolvidas na leitura; blocos de texto em várias linhas (| e >) e suas variantes (|-, >-, |+, >+) viram o texto correto. Se suas âncoras ou textos em várias linhas derem erro, é um problema de sintaxe de verdade — o validador não está sendo mais rígido que a especificação.
- Meu YAML é enviado para algum lugar?
- Não. A leitura roda inteira no seu navegador. Nada é registrado, guardado ou enviado a um servidor. Você pode desligar a internet e a ferramenta continua funcionando.
- Por que meu arquivo falha na linha 1, coluna 1, se parece estar certo?
- Na maioria das vezes: um BOM (marca de ordem de bytes) UTF-8 no começo do arquivo, um espaço inseparável onde deveria haver um espaço comum, ou o documento começa com tab. Salve o arquivo como UTF-8 sem BOM e confira a primeira linha atrás de caracteres invisíveis — muitos editores têm uma opção 'mostrar espaços em branco' ou 'mostrar caracteres de controle' que revela isso.
