Pular para o conteúdo

Formatador e validador de YAML

YAML Formatter & Validator

Reindenta YAML de forma consistente, valida e aponta os erros de tabulação e âncora que quebram os parsers.

Reindenta um arquivo YAML de forma consistente e diz o que outro parser leria diferente. É um leitor de YAML 1.2 que mantém comentários, âncoras, tags e escalares de bloco, então a saída é o seu documento com o layout consertado — não uma ida e volta por um modelo de dados que teria jogado seus comentários fora.

🔒 Roda inteiramente no seu navegadoryamlformatvalidateconfig
Saída
Indentação

YAML de entrada

Solte um arquivo .yaml

Lido só nesta aba. Nada é enviado.

YAML formatado

Formatado.

Foi lido, mas os parsers podem discordar destes pontos

  • 19:22 — `no` é a string "no" no YAML 1.2. Um parser de YAML 1.1 lê isso como booleano — ponha aspas, ou escreva true/false, para os dois concordarem.

Documentos

1

Chaves

30

Itens de lista

8

Âncoras / aliases

1 / 1

Avisos

1

O que este formatador faz e o que não faz

  • · Lido com o schema core do YAML 1.2. yes e no e on e off são strings, e 0755 é o 755 decimal, não octal. Os valores que um parser de 1.1 leria de outro jeito aparecem acima como avisos.
  • · Comentários, âncoras (&), aliases (*), tags e os escalares de bloco | e > são todos preservados. A ordem dos valores também não muda.
  • · Indentação com tabulação, chaves duplicadas, um alias usado antes de ser definido e uma aspa não fechada são todos pegos como erro, com linha e coluna.
  • · A chave de mesclagem << é um recurso do 1.1, mas docker-compose e Ansible a usam tanto que ela é aplicada na conversão para JSON — com um aviso dizendo isso.
  • · Um comentário dentro de uma coleção em fluxo como [a, b] não tem linha a que se prender e se perde. Todos os outros comentários sobrevivem.

Para converter para JSON ou TOML use o conversor JSON ⇄ YAML, e para conferir um documento contra um schema use o validador de JSON Schema.

Como usar

  1. Cole o manifesto ou a configuração

    Um manifesto Kubernetes, um arquivo de CI, um docker-compose. Vários documentos separados por `---` são lidos como um stream e contados separadamente.

  2. Escolha o estilo de lista

    A única opção sobre a qual as pessoas de fato discutem: se `- item` fica no nível da chave ou indentado abaixo dela. Os dois são YAML válido; manifestos Kubernetes usam por convenção a forma no mesmo nível.

  3. Leia os avisos

    Valores cujo significado depende de qual versão de YAML o leitor implementa — `yes`, `no`, `0755` — são listados com linha e coluna. São os que quebram um deploy em outra ferramenta.

  4. Ou mude a saída para JSON

    A mesma análise, renderizada como JSON, que é o jeito mais rápido de ver em que um valor realmente resolveu — inclusive no que uma chave de merge se expandiu.

Perguntas frequentes

Por que `no` é uma string aqui?

Porque o esquema core do YAML 1.2 diz isso: os únicos booleanos são `true` e `false`. YAML 1.1 — que o PyYAML ainda usa por padrão — lê `no`, `off` e `n` como falso. Qualquer valor em que os dois discordam é marcado como aviso, porque é uma diferença real de comportamento, não de estilo.

Minhas âncoras e aliases são preservados?

Na saída YAML, sim: `&res` e `*res` saem como você escreveu, e a contagem aparece nas estatísticas. A visão JSON tem de expandi-los, porque JSON não tem como dizer “o mesmo nó de novo”.

Ele suporta chaves de merge?

`<<:` é um recurso do YAML 1.1, não parte do 1.2 — mas arquivos docker-compose e Ansible o usam o tempo todo, então ele é aplicado ao converter para JSON, com um aviso dizendo que foi isso que aconteceu. Na saída YAML é deixado exatamente como escrito.

Um comentário sumiu. Por quê?

Quase com certeza ele estava dentro de uma coleção de fluxo: `[a, # nota\n b]`. Uma coleção de fluxo é reimpressa como uma linha só, e um comentário ali não tem linha em que se prender. Todo comentário em linha própria, ou no fim de um valor, sobrevive.

Pode receber de

Em seguida

Estas aceitam o que esta ferramenta produz, então o resultado pode ir direto.