- ¿Qué significa realmente “YAML válido”?
- YAML tiene una gramática estricta: la sangría debe ser coherente (solo espacios, sin tabulaciones), los mapeos necesitan dos puntos seguidos de un espacio, las colecciones en línea (las formas [...] y {...}) deben cerrarse, y las cadenas con caracteres especiales deben ir entre comillas. Aquí “válido” significa que el documento se analiza sin errores según la especificación YAML 1.2 con el esquema de tipos compatible con JSON, el mismo subconjunto al que apuntan los manifiestos de Kubernetes, los flujos de GitHub Actions y los archivos de Docker Compose. Si se analiza aquí, se analizará en esas herramientas.
- ¿Por qué el número de línea no coincide con mi editor?
- Debería coincidir: mostramos líneas y columnas empezando en 1, igual que VS Code, JetBrains, vim y la mayoría de los editores. js-yaml usa internamente posiciones que empiezan en 0; les sumamos 1 antes de mostrarlas. Si no coinciden, comprueba que tu editor y el validador ven el mismo contenido (un salto de línea final o un BOM al principio pueden desplazar una línea).
- ¿Por qué “yes”, “no”, “on”, “off” se tratan como cadenas?
- YAML 1.1 los convertía en booleanos, lo que causó el famoso “problema de Noruega” (el código de país NO se leía como el booleano false). YAML 1.2, y el JSON_SCHEMA que usa este validador, los mantienen como cadenas normales, igual que Kubernetes, GitHub Actions, Docker Compose y la mayoría de los analizadores modernos. Si quieres booleanos, escribe “true” o “false” explícitamente.
- ¿Admite YAML con varios documentos (separadores ---)?
- Sí. El validador analiza el flujo completo e indica cuántos documentos encontró. El YAML con varios documentos es habitual en los manifiestos de Kubernetes (cada --- separa un Service, un Deployment, un ConfigMap, etc.). Si cualquier documento del flujo no es válido, la validación falla con la línea y la columna contadas desde el inicio del texto.
- ¿Qué diferencia hay con un convertidor de YAML a JSON?
- El propósito. El convertidor supone que tu YAML es válido y te da JSON. El validador se centra en decirte si es válido y, si no lo es, dónde está exactamente el error. Usa el validador cuando algo posterior (kubectl, GitHub Actions, ansible-playbook) rechaza tu archivo y necesitas encontrar el fallo rápido.
- ¿El analizador detecta todo tipo de errores?
- Detecta todos los errores de sintaxis: sangría incorrecta, comillas sin cerrar, colecciones en línea sin cerrar, anclas no válidas. NO detecta errores semánticos respecto a un esquema (por ejemplo, “a este Deployment de Kubernetes le falta un campo obligatorio” o “el nombre de este paso de GitHub Actions está mal escrito”). Para validar contra un esquema necesitas el validador de la herramienta de destino (kubectl --dry-run, actionlint, etc.).
- ¿Y las anclas, las referencias y las cadenas multilínea?
- Totalmente admitidas. Las anclas (&nombre) y referencias (*nombre) se resuelven al analizar; los bloques escalares multilínea (| y >) y sus variantes de recorte (|-, >-, |+, >+) se convierten en el contenido de texto correcto. Si tus anclas o cadenas multilínea dan error, es un problema de sintaxis real: el validador no es más estricto que la especificación.
- ¿Se sube mi YAML a algún sitio?
- No. El análisis se hace por completo en tu navegador. Nada se registra, se guarda ni se envía a un servidor. Puedes desconectarte de la red y la herramienta sigue funcionando.
- ¿Por qué mi archivo falla en la línea 1, columna 1, aunque se ve bien?
- Lo más habitual: una marca de orden de bytes (BOM) UTF-8 al principio del archivo, un espacio de no separación donde esperarías un espacio normal, o que el documento empieza con una tabulación. Guarda el archivo como UTF-8 sin BOM y revisa la primera línea en busca de caracteres invisibles; muchos editores tienen una opción de “mostrar espacios en blanco” o “mostrar caracteres de control” que los hace visibles.
