Normaliza y valida sintaxis TOML sin dependencias externas
Validación básica de sintaxis (claves duplicadas, comillas sin cerrar, líneas mal formadas). Para validación semántica completa de tipos TOML, usa un linter dedicado.
Pega TOML arriba para validar y normalizar su sintaxis
También podrías necesitar
TOML (Tom's Obvious, Minimal Language) es el formato de configuración preferido por el ecosistema Rust (Cargo.toml), Python moderno (pyproject.toml, PEP 518/621), y herramientas como Hugo, Netlify y Poetry. Su gramática es intencionalmente pequeña y explícita: claves = valor, secciones entre [corchetes], arrays de tablas con [[dobles corchetes]], y tipos claros para strings, enteros, floats, booleanos, datetimes y arrays. Esta herramienta implementa un validador y normalizador básico de sintaxis TOML sin dependencias externas: detecta claves duplicadas en la misma sección, líneas sin '=' que no son comentarios ni secciones, comillas sin cerrar, y aplica un formato consistente (un espacio antes y después del =, línea en blanco entre secciones). Es útil para revisar archivos de configuración antes de commit y para detectar errores comunes al escribir TOML manualmente. Para validación semántica completa (verificar tipos, evaluar datetimes, resolver inline tables anidadas), usa un linter TOML dedicado — pero para la mayoría de errores en Cargo.toml, pyproject.toml y configuraciones simples, esta herramienta es suficiente.
¿Por qué la herramienta indica que la validación es 'básica'?
TOML tiene tipos complejos (datetimes con timezone, inline tables anidadas, arrays heterogéneos con tipos mixtos, strings multi-línea con comillas triples) cuyo parsing completo requiere un parser especializado. Esta herramienta implementa validación de sintaxis a nivel de línea (clave = valor, secciones bien formadas, comillas cerradas, claves duplicadas), suficiente para detectar la mayoría de errores comunes. Para validación semántica completa, usa un parser TOML dedicado en tu build pipeline.
¿Qué diferencia hay entre [section] y [[section]]?
[section] define una tabla (equivalente a un objeto JSON con la clave 'section'). [[section]] define un array de tablas: cada aparición de [[section]] añade un nuevo elemento al array. Es el patrón usado en Cargo.toml para declarar múltiples dependencias con versiones distintas, y en pyproject.toml para múltiples build hooks.
¿Preserva los comentarios?
Sí. Los comentarios (líneas que empiezan con # o texto tras # en una línea de valor) se preservan en el output formateado en su posición original. Los comentarios inline al final de una línea de clave = valor también se mantienen.
¿Detecta claves duplicadas?
Sí. La especificación TOML prohíbe explícitamente redefinir una clave en la misma sección. Si tu TOML tiene, por ejemplo, dos entradas 'name = ' en la misma sección [package], el validador lo detecta y muestra el número de línea donde ocurre.
¿Cuándo usar TOML vs YAML vs JSON?
TOML es preferible para configuración humana estructurada donde la legibilidad y la ausencia de sorpresas importa (Cargo.toml, pyproject.toml). YAML es mejor cuando necesitas jerarquías profundas con muchos niveles y quieres máxima concisión (Kubernetes, Docker Compose) aunque su parser es más complejo. JSON es ideal para comunicación máquina-a-máquina (APIs), pero es tedioso para escribir a mano (obligatorias comillas, sin comentarios). Muchos proyectos modernos eligen TOML para su config principal por su balance entre simplicidad y potencia.