Converter YAML para JSON — Python, yq, navegador (evite 8 armadilhas)

TL;DR — escolha um método em 10 segundos

• Precisa agora, sem instalar nada → FormatArc YAML para JSON (roda no navegador, sem upload, valida enquanto converte, erros com número de linha)
• CLI / one-liner → yq -o=json '.' file.yaml (o padrão do DevOps)
• Script ou pipeline em Python → python3 -c 'import sys, yaml, json; json.dump(yaml.safe_load(sys.stdin), sys.stdout, indent=2)' < file.yaml
• Aplicação Node.js → js-yaml (yaml.load) + JSON.stringify
• Serviço em Go → gopkg.in/yaml.v3 + encoding/json
• Round-trip no Kubernetes → kubectl get ... -o json | yq -P '.' (de volta para YAML)
• YAML multi-documento (separadores ---) → yq -o=json '.' file.yaml (o yq separa por padrão) ou saída NDJSON

A maior parte das conversões de YAML para JSON é uma única linha de código. As partes difíceis são as 8 armadilhas (problema da Noruega, comentários perdidos, tratamento de multi-documento, yaml.load ser inseguro, chaves inteiras virando strings, expansão de âncoras, 1.0 virando float, surpresas na inferência de tipos) que este guia explica com exemplos antes/depois verificados.

Por que converter YAML para JSON?

Alguns cenários comuns:

• Envio para a API do Kubernetes: você tem um manifesto em YAML, mas precisa fazer o POST pela API do Kubernetes, que só aceita corpos codificados em JSON.
• Depurar a estrutura do YAML: o aninhamento por indentação do YAML às vezes é ambíguo — converter para JSON torna a estrutura inequívoca. Um - fora do lugar ou uma indentação errada saltam aos olhos imediatamente no JSON.
• Ferramentas que só aceitam JSON: a sua ferramenta downstream (um parser JSON em outra linguagem, um banco que armazena JSON, um event bus com validador de JSON Schema) não aceita YAML.
• Auditoria de configuração: converta configs em YAML de um repositório para JSON e faça análise de diff, validação contra JSON Schema ou alimentação de scanners de segurança.
• Contexto para LLM: forneça configs a uma LLM como JSON — o modelo lida com os limites de objetos JSON de forma mais confiável do que com a indentação do YAML, especialmente em estruturas aninhadas. Veja Markdown vs HTML para LLMs para o guia de escolha de formato.

Entender as diferenças entre YAML e JSON ajuda a evitar surpresas durante a conversão. Veja YAML vs JSON para uma comparação aprofundada.

Método 1: ferramenta no navegador FormatArc (sem upload)

Para conversões rápidas e pontuais sem instalar nada, o conversor de YAML para JSON é a opção mais simples. Ele roda inteiramente no seu navegador — nenhum dado sai da sua máquina.

1. Abra a ferramenta YAML para JSON.
2. Cole o seu YAML no painel da esquerda.
3. Clique em Converter. A saída JSON aparece no painel da direita.

A ferramenta valida o seu YAML enquanto converte. Erros de sintaxe — indentação errada, dois-pontos faltando, tabs onde se esperam espaços — são reportados com o número da linha, o que a torna útil para depurar arquivos YAML mesmo quando a conversão não é o objetivo principal.

A conversão no navegador importa quando o YAML contém dados sensíveis: Kubernetes Secrets (sim, os dados são codificados em base64, mas ainda assim confidenciais), credenciais de provedor de nuvem em arquivos do Ansible vault, configs internas de CI com tokens de API. Nada sai da aba.

Isso não é uma preocupação teórica. Em novembro de 2025, a empresa de segurança watchTowr descobriu que os populares sites de formatação JSONFormatter e CodeBeautify expuseram mais de 5GB de dados salvos por usuários — incluindo credenciais, chaves privadas e tokens de API — por meio de um recurso de salvar que deixava a entrada armazenada navegável publicamente (relatório da watchTowr). Uma ferramenta que roda no navegador não tem nada a expor porque nunca armazena nem transmite a sua entrada.

Veja Os conversores JSON online são seguros? para saber como verificar antes de colar.

A ferramenta no navegador lida com: strings de múltiplas linhas (tanto o estilo de bloco literal | quanto o dobrado >), âncoras e aliases (expandidos inline), estruturas aninhadas de profundidade arbitrária, arrays de tipos mistos, valores nulos, booleanos e tipos numéricos.

Método 2: yq (o padrão do DevOps)

yq é um processador de YAML leve em linha de comando — pense no jq, mas para YAML. É de longe a ferramenta mais comum para conversão de YAML para JSON em pipelines de DevOps.

# Conversão básica
yq -o=json '.' input.yaml

# Pipe a partir do stdin
cat config.yaml | yq -o=json '.'

# Salvar em arquivo
yq -o=json '.' config.yaml > config.json

# Saída compacta (uma única linha)
yq -o=json -I=0 '.' config.yaml

# Extrair uma sub-árvore durante a conversão
yq -o=json '.spec.template' deployment.yaml

# Converter e aplicar um filtro
yq -o=json '.items[] | select(.kind == "ConfigMap")' multi.yaml

Instalação:

# macOS
brew install yq

# Linux (snap)
snap install yq

# Linux (download do binário)
sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
sudo chmod +x /usr/local/bin/yq

# Go install
go install github.com/mikefarah/yq/v4@latest

Observação: existem duas ferramentas concorrentes, ambas chamadas yq. Este guia usa o yq do Mike Farah, baseado em Go (usado em todo lugar nas ferramentas de Kubernetes / CNCF). O yq em Python, do kislyuk, usa uma sintaxe diferente — ambos funcionam, mas a versão em Go é o padrão de fato em 2026.

yq com JSON Lines (YAML multi-documento)

# Arquivo YAML multi-documento (vários documentos separados por ---)
yq -o=json '.' multi.yaml          # gera um documento JSON por doc de entrada
yq -o=json -I=0 '.' multi.yaml      # NDJSON (compacto, um por linha)
yq eval-all '[.]' -o=json multi.yaml  # agrupa todos os docs em um único array JSON

Essa é a forma mais limpa de converter arquivos de "lista de recursos" do Kubernetes em um único array JSON para operações em lote na API.

Método 3: Python (o mais flexível)

O Python já vem com um módulo JSON na biblioteca padrão, e o pyyaml está instalado por padrão na maioria dos sistemas (ou via pip install pyyaml).

One-liner em Python

python3 -c 'import sys, yaml, json; json.dump(yaml.safe_load(sys.stdin), sys.stdout, indent=2)' < input.yaml > output.json

Isso lê o YAML do stdin, faz o parse com yaml.safe_load e escreve JSON formatado no stdout. O argumento indent=2 produz uma saída legível.

Script em Python (multi-documento, tratamento de erros)

import sys
import yaml
import json

with open("config.yaml") as f:
    data = yaml.safe_load(f)  # use safe_load_all() para multi-documento

with open("config.json", "w") as f:
    json.dump(data, f, indent=2, ensure_ascii=False)

yaml.safe_load é importante — ele evita a execução arbitrária de código que o yaml.load permite. Use sempre a variante segura, a menos que tenha um motivo específico para não fazê-lo (veja a armadilha #4 abaixo).

Python com ruamel.yaml (preserva mais estrutura)

Para necessidades mais avançadas, o ruamel.yaml preserva o estilo das aspas, a ordem das chaves e até os comentários (embora os comentários ainda não sobrevivam ao JSON):

from ruamel.yaml import YAML
import json
import sys

yaml_parser = YAML(typ="safe")
data = yaml_parser.load(open(sys.argv[1]))
json.dump(data, sys.stdout, indent=2, ensure_ascii=False)

Para a maioria dos casos de uso, pyyaml.safe_load é suficiente. Use ruamel.yaml se precisar preservar a formatação do YAML em round-trip.

Método 4: Node.js (js-yaml)

O pacote js-yaml é a escolha padrão para aplicações Node.js.

const fs = require("fs");
const yaml = require("js-yaml");

// Documento único
const doc = yaml.load(fs.readFileSync("config.yaml", "utf8"));
fs.writeFileSync("config.json", JSON.stringify(doc, null, 2));

// Multi-documento
const docs = yaml.loadAll(fs.readFileSync("multi.yaml", "utf8"));
fs.writeFileSync("multi.json", JSON.stringify(docs, null, 2));

Instalação: npm install js-yaml ou yarn add js-yaml.

Para entrada YAML não confiável, use yaml.load(text, { schema: yaml.JSON_SCHEMA }) para restringir apenas a tipos compatíveis com JSON. O DEFAULT_SCHEMA padrão inclui algumas peculiaridades do YAML 1.1, como o problema da Noruega.

Método 5: Go (gopkg.in/yaml.v3)

package main

import (
    "encoding/json"
    "fmt"
    "os"

    "gopkg.in/yaml.v3"
)

func main() {
    data, _ := os.ReadFile("config.yaml")
    var obj interface{}
    yaml.Unmarshal(data, &obj)
    result, _ := json.MarshalIndent(obj, "", "  ")
    fmt.Println(string(result))
}

yaml.v3 é a versão mantida pelo go-yaml (a mesma usada pelo próprio Kubernetes). Uma ressalva: chaves inteiras em YAML (123: foo) são convertidas em strings no JSON, já que o JSON só aceita chaves do tipo string (veja a armadilha #5).

Para fazer streaming de arquivos YAML multi-documento, use yaml.NewDecoder em um loop:

dec := yaml.NewDecoder(file)
for {
    var doc interface{}
    if err := dec.Decode(&doc); err != nil {
        if err == io.EOF { break }
        log.Fatal(err)
    }
    out, _ := json.Marshal(doc)
    fmt.Println(string(out))   // NDJSON: um documento por linha
}

Isso lida com arquivos YAML multi-documento arbitrariamente grandes usando memória constante.

Armadilhas da conversão de YAML — 8 casos verificados

YAML e JSON não têm um mapeamento perfeito de um-para-um. Estas são as coisas que mais costumam pegar as pessoas.

Armadilha 1: o problema da Noruega (NO → false)

O YAML 1.1 interpreta certas strings sem aspas como booleanos:

country: NO

Vira:

{ "country": false }

NO, no, Off, OFF, n, N, False, False, f, F todos viram false. YES, Y, On, True, T, t todos viram true. Esse é o famoso "problema da Noruega" — country: NO em uma lista de códigos de país é silenciosamente interpretado como um booleano.

Correção: coloque entre aspas os valores ambíguos no seu YAML:

country: "NO"

O YAML 1.2 (especificamente o schema Core) removeu esse comportamento. Mas muitas ferramentas ainda usam YAML 1.1 por padrão, incluindo o safe_load do PyYAML e o yq até a v4. Coloque sempre entre aspas códigos de país de duas letras, strings de versão como 1.0 e qualquer campo de string controlado pelo usuário.

Armadilha 2: comentários são silenciosamente perdidos

O YAML suporta comentários com #. O JSON não. Quaisquer comentários no seu arquivo YAML são descartados durante a conversão:

# Conexão com o banco de produção (NÃO ALTERAR)
host: db.prod.internal
port: 5432  # porta padrão do PostgreSQL

Vira:

{ "host": "db.prod.internal", "port": 5432 }

Nenhum conversor consegue preservar comentários YAML no JSON, porque o JSON não tem sintaxe de comentário. JSON5 e JSONC têm, mas não são padrão. Se os comentários forem importantes, salve-os separadamente ou use uma ferramenta como ruamel.yaml para extraí-los programaticamente antes da conversão.

Armadilha 3: YAML multi-documento (---) — só o primeiro documento sobrevive por padrão

Arquivos YAML podem conter vários documentos separados por ---:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: v1
kind: Service
metadata:
  name: app-service

Comportamento padrão:

• yaml.safe_load (Python): retorna apenas o primeiro documento, silenciosamente
• yaml.load (js-yaml): igual, retorna apenas o primeiro
• yq -o=json '.': emite vários documentos JSON em sequência (concatenados, NDJSON válido se compacto)

Para obter todos os documentos como um array JSON:

yq eval-all '[.]' -o=json multi.yaml

Python:

import yaml, json
docs = list(yaml.safe_load_all(open("multi.yaml")))
json.dump(docs, open("multi.json", "w"), indent=2)

Node.js:

const docs = yaml.loadAll(fs.readFileSync("multi.yaml", "utf8"));
fs.writeFileSync("multi.json", JSON.stringify(docs, null, 2));

Arquivos de "lista de manifestos" do Kubernetes quase sempre usam YAML multi-documento. Trate esse caso explicitamente.

Armadilha 4: yaml.load é inseguro — use sempre safe_load

No PyYAML do Python, a função padrão yaml.load permite a construção arbitrária de objetos Python:

!!python/object/apply:os.system ["rm -rf /"]

Um arquivo YAML criado de forma maliciosa pode executar código se for carregado com yaml.load. Use sempre yaml.safe_load (ou yaml.safe_load_all para multi-documento) ao lidar com entrada não confiável.

O js-yaml mitigou isso ao deprecar yaml.safeLoad em favor de yaml.load, mas o yaml.load no js-yaml é seguro por padrão. O unsafeLoad, depreciado, é o perigoso. A nomenclatura é confusamente diferente entre Python e Node — verifique sempre.

O yq é seguro porque usa o yaml.v3 do Go, que não tem nada equivalente à tag !!python/object do Python.

Armadilha 5: chaves inteiras viram strings

O YAML permite chaves inteiras:

123: first
456: second

As chaves de objetos JSON precisam ser strings, então os conversores fazem o cast:

{ "123": "first", "456": "second" }

Isso normalmente não é problema, mas se o seu código downstream espera fazer lookup por uma chave inteira (obj[123]), ele vai falhar porque a chave agora é uma string (obj["123"]). Converta as chaves de volta para inteiros no código da aplicação, se necessário.

Armadilha 6: âncoras e aliases são expandidos inline

O YAML permite definir um valor uma vez com &anchor e referenciá-lo em outro lugar com *alias:

defaults: &defaults
  timeout: 30
  retries: 3

production:
  <<: *defaults
  host: prod.internal

staging:
  <<: *defaults
  host: stage.internal

Quando convertido para JSON, a âncora é expandida inline — tanto production quanto staging acabam com uma cópia completa de cada default:

{
  "defaults": { "timeout": 30, "retries": 3 },
  "production": { "timeout": 30, "retries": 3, "host": "prod.internal" },
  "staging": { "timeout": 30, "retries": 3, "host": "stage.internal" }
}

Os dados estão corretos, mas a intenção original de "estes compartilham os defaults" deixa de ser visível. Se você converter de volta para YAML, perde as âncoras por completo. Isso é inevitável — o JSON não tem nada equivalente a âncoras.

Armadilha 7: 1.0 vira um float (strings de versão quebram)

O YAML trata valores que parecem números como números:

version: 1.0
release: 2026

Vira:

{ "version": 1.0, "release": 2026 }

Se você queria a string "1.0" (um rótulo de versão), a conversão silenciosamente a transforma em um float 1.0, que depois é impresso como 1 ou 1.0 dependendo do encoder JSON. Comparações de versão major (if version == "1.0") vão falhar.

Correção: coloque as strings de versão entre aspas no YAML:

version: "1.0"
release: "2026"

Isso vale para qualquer coisa que deva permanecer string mas que por acaso pareça numérica: números de telefone, CEPs ("01234" perde o zero à esquerda), hashes de commit que parecem números hexadecimais ("e10" → 1e+10).

Armadilha 8: surpresas na inferência de tipos por schema

O YAML tem três schemas padrão que determinam como os tipos são inferidos:

• Schema FailSafe: apenas strings, sequências e mapeamentos. Sem parsing de números ou booleanos. O mais seguro.
• Schema JSON: corresponde aos tipos do JSON (strings, números, booleanos, null, arrays, objetos). Sem o problema da Noruega, sem booleanos yes/no.
• Schema Core (padrão do YAML 1.2): como o JSON, mas adiciona null, Null, NULL, ~ e o vazio como null. Também aceita true/false/True/False/TRUE/FALSE como booleanos.

A maioria das ferramentas usa o Core por padrão. Algumas ferramentas legadas usam o schema completo do YAML 1.1 (que inclui o problema da Noruega e yes/no).

Para forçar o schema JSON em Python:

yaml.safe_load(text, Loader=yaml.SafeLoader)  # padrão
# ou seja explícito:
yaml.load(text, Loader=yaml.CSafeLoader)

js-yaml:

yaml.load(text, { schema: yaml.JSON_SCHEMA });

O yq v4 usa o schema Core do YAML 1.2 por padrão, o que evita o problema da Noruega.

Comparação de ferramentas online

Uma comparação prática dos conversores online de YAML para JSON mais comuns em 2026:

Para YAML sensível (Kubernetes Secrets, conteúdo de Ansible vault, configs de CI com tokens), a alegação de "rodar no navegador" importa. Verifique desabilitando a rede no DevTools antes de colar — uma ferramenta verdadeiramente local continua funcionando sem rede. O FormatArc continua funcionando com a rede desabilitada.

Para YAML multi-documento, todas as ferramentas online listadas lidam apenas com o primeiro documento. Para saída multi-documento ou NDJSON, recorra ao yq ou ao Python.

YAML para JSON Lines (NDJSON) em pipelines de streaming

Quando a entrada é um arquivo YAML multi-documento e a saída precisa alimentar um consumidor de streaming (produtor Kafka, carregador linha-a-linha de banco de dados, log shipper), o JSON Lines (NDJSON) é o formato de saída correto.

Com yq

# NDJSON: cada documento YAML vira uma linha JSON
yq -o=json -I=0 '.' multi.yaml

# Filtrar e depois NDJSON
yq -o=json -I=0 '.items[]' kubernetes-list.yaml

Com streaming em Python

import yaml
import json
import sys

for doc in yaml.safe_load_all(sys.stdin):
    sys.stdout.write(json.dumps(doc, ensure_ascii=False) + "\n")

Uso: python3 yaml2ndjson.py < multi.yaml > multi.ndjson.

Isso consome memória constante independentemente do tamanho da entrada — importante para arquivos YAML em estilo de log com milhares de documentos.

Pipe para Kafka, BigQuery ou S3

# Stream para o BigQuery
yq -o=json -I=0 '.' events.yaml | bq load --source_format=NEWLINE_DELIMITED_JSON dataset.events -

# Stream para o S3
yq -o=json -I=0 '.' events.yaml | aws s3 cp - s3://bucket/events.ndjson

# Stream para o Kafka via kafkacat
yq -o=json -I=0 '.' events.yaml | kafkacat -P -b broker:9092 -t events

Automação de CI/CD

Três plataformas de pipeline comuns com etapas de conversão de YAML para JSON.

GitHub Actions

name: Convert YAML config to JSON
on: [push, pull_request]

jobs:
  convert:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install yq
        run: |
          sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
          sudo chmod +x /usr/local/bin/yq
      - name: Convert
        run: yq -o=json '.' config.yaml > config.json
      - name: Validate against JSON Schema
        run: |
          npx ajv-cli validate -s schema.json -d config.json

GitLab CI

convert-yaml:
  image: mikefarah/yq:latest
  stage: validate
  script:
    - yq -o=json '.' config.yaml > config.json
    - jq empty config.json   # verificação final de sintaxe
  artifacts:
    paths:
      - config.json

Jenkins (pipeline declarativo)

pipeline {
  agent any
  stages {
    stage('Convert YAML to JSON') {
      steps {
        sh 'yq -o=json . config.yaml > config.json'
        sh 'jq empty config.json'
      }
    }
  }
}

De qualquer forma, a conversão adiciona menos de um segundo ao tempo de execução do pipeline.

Fluxo prático no Kubernetes

Um cenário típico do mundo real. Você tem um deployment em execução, quer inspecioná-lo ou modificá-lo e precisa converter entre YAML e JSON.

# Obter o deployment atual como JSON (o kubectl suporta ambos)
kubectl get deployment web-app -o json > deployment.json

# Ou obter como YAML e converter (verifica o seu yq local)
kubectl get deployment web-app -o yaml | yq -o=json '.' > deployment.json

# Modificar com jq (ex.: escalar réplicas)
jq '.spec.replicas = 5' deployment.json > updated.json

# Converter de volta para YAML para commitar no Git
yq -P '.' updated.json > deployment.yaml

# Aplicar
kubectl apply -f deployment.yaml

Ou em um único pipeline:

kubectl get deployment web-app -o json \
  | jq '.spec.replicas = 5' \
  | yq -P '.' \
  > deployment.yaml

Esse padrão funciona em todos os recursos do kubectl, valores de Helm chart e custom resource definitions.

Perguntas frequentes

Por que o meu valor YAML country: NO virou false?

Esse é o famoso "problema da Noruega". O YAML 1.1 interpreta NO, Off, n, False e strings sem aspas semelhantes como o booleano false. Corrija colocando entre aspas: country: "NO". A especificação do YAML 1.2 removeu esse comportamento, mas muitas ferramentas ainda usam a 1.1 por padrão. O yq v4 usa o schema Core do YAML 1.2 e não tem esse bug.

Posso preservar os comentários do YAML na saída JSON?

Não. O JSON não tem sintaxe de comentário. Soluções incluem usar o ruamel.yaml para extrair os comentários como uma estrutura de metadados separada, ou formatos não padrão como JSON5 / JSONC. Se os comentários forem importantes, mantenha o YAML como fonte da verdade. Veja Como adicionar comentários ao JSON para soluções dentro do próprio JSON.

YAML multi-documento — o que acontece durante a conversão?

Por padrão, a maioria das ferramentas converte apenas o primeiro documento. Para obter todos os documentos: use yaml.safe_load_all em Python, yaml.loadAll em Node.js, ou yq eval-all '[.]' para agrupar em um array JSON. Para streaming (um documento JSON por linha), use yq -o=json -I=0 para saída NDJSON.

YAML para JSON Lines (NDJSON)?

Use yq -o=json -I=0 '.' multi.yaml para uma saída compacta de um documento por linha. Em Python: faça streaming com yaml.safe_load_all e escreva cada um como uma linha. NDJSON é o formato certo para consumidores de streaming (BigQuery, S3, Kafka, log shippers).

YAML para JSON5 (com comentários)?

JSON5 é um superset do JSON que permite comentários. Para converter YAML para JSON5: converta o YAML para JSON padrão primeiro, depois adicione os comentários de volta manualmente, ou use uma ferramenta personalizada. A implementação de referência do json5.org consegue fazer parse e emitir JSON5, mas nenhuma biblioteca YAML importante gera JSON5 diretamente.

Âncoras e merge keys — são preservadas no JSON?

Não. O JSON não tem o conceito de âncora / alias, então as âncoras são expandidas inline durante a conversão. Os dados expandidos estão corretos, mas a intenção original de "estes compartilham os defaults" deixa de ser visível no JSON. Converter de volta para YAML perde as âncoras por completo.

Como converto um arquivo YAML para JSON sem yq ou Python instalados?

Use a ferramenta YAML para JSON no navegador do FormatArc — ela roda inteiramente no navegador, sem necessidade de instalação. Como alternativa, todo SO moderno já vem com Python 3 (que pode usar o pyyaml após pip install pyyaml). Em muitas distribuições Linux, python3 -c 'import sys, yaml, json; ...' funciona de imediato.

Indo na direção contrária

Para converter JSON para YAML, veja Como converter JSON para YAML. A ferramenta JSON para YAML do FormatArc lida com a direção reversa com a mesma facilidade.

Guias relacionados

• O que é YAML — o modelo de dados do YAML, sua história e casos de uso comuns
• O que é JSON — o modelo de dados e os tipos do JSON
• Guia de sintaxe do YAML — escrevendo YAML válido do zero
• YAML vs JSON — comparação estrutural e quando usar cada um
• Conversão de JSON para YAML — a direção reversa
• Dicas de formatação de JSON — produza um JSON revisável após a conversão

Resumo

Cinco métodos cobrem todos os casos de uso de YAML para JSON:

• Sem instalação, dados sensíveis: FormatArc YAML para JSON — roda no navegador, erros com número de linha.
• CLI / pipelines de DevOps: yq -o=json '.' — o padrão de fato.
• Aplicações Python: yaml.safe_load (nunca yaml.load) + json.dump.
• Aplicações Node.js: js-yaml (yaml.load com schema JSON por segurança).
• Serviços em Go: gopkg.in/yaml.v3 + encoding/json, com um loop de Decoder para arquivos multi-documento.

As 8 armadilhas (problema da Noruega, comentários perdidos, tratamento de multi-documento, insegurança do yaml.load, chaves inteiras virando strings, expansão de âncoras, 1.0 virando float, inferência de tipos por schema) pegam quase todo mundo pelo menos uma vez. Coloque strings ambíguas entre aspas, use safe_load e trate o multi-documento explicitamente — o resto vem por consequência.