SOML, el formato de config que quiere reemplazar a YAML

Qué es SOML y por qué aparece ahora

SOML es un nuevo formato de configuración para archivos que las personas escriben y leen a mano. Sus siglas significan Sindre's Objectively Marvelous Language, y su autor es Sindre Sorhus, una figura muy conocida en el ecosistema de JavaScript por su trabajo en herramientas de código abierto. La especificación está publicada como borrador en su repositorio de GitHub, con una advertencia explícita: draft spec, feedback welcome.

La propuesta no es menor. SOML se presenta como un punto medio entre JSON y YAML: quiere la comodidad de escribir de YAML y el rigor de JSON, sin la ambigüedad que arrastra el primero. En la práctica, es un intento de responder a una pregunta que cualquier equipo de desarrollo se hizo alguna vez: ¿por qué un archivo de configuración puede comportarse distinto según qué parser lo lea?

La regla central: el tipo viene de la sintaxis, no del contenido

Toda la especificación de SOML se apoya en una sola idea: el tipo de un valor se deduce de su sintaxis, nunca de su contenido. Eso significa que '123' es un string y 123 es un entero, sin importar el contexto. Nada se "re-tipa" inspeccionando el valor.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

De ahí salen varias decisiones concretas:

Un string siempre lleva comillas. Un valor sin comillas debe ser un número, una fecha, un instante, una duración o una palabra clave; si no lo es, el archivo da error.
Las fechas como 2026-09-19, los instantes como 2026-09-19T14:00:00Z y las duraciones como 30s o 1h30m son tipos reales, no strings que cada lector deba interpretar.
Las rutas de Windows y las expresiones regulares no necesitan escape, porque los strings literales se escriben entre comillas simples.
La indentación es libre: la estructura la dan las llaves y los saltos de línea, no los espacios.

El resultado, según el propio autor, es que timeout: 30 deja de ser ambiguo: con 30s nadie tiene que adivinar la unidad.

Qué problemas de YAML y TOML dice resolver

La especificación dedica buena parte de su texto a documentar los errores clásicos de los formatos actuales. No son hipótesis: son comportamientos verificables de parsers muy usados.

En YAML, el contenido decide el tipo. Según el repositorio, en PyYAML (que sigue YAML 1.1) country: no se convierte en false, zip: 01234 se lee como octal 668 y time: 22:22 como base-60 1342. YAML 1.2 corrigió esos casos, pero la mayoría del ecosistema sigue en 1.1, y 1.2 todavía adivina: version: 3.10 se interpreta como el float 3.1. SOML elimina el problema porque los strings siempre llevan comillas, así que country: no es directamente un error.

El repositorio también señala que los parsers no coinciden entre sí. En la matriz de pruebas de YAML (última instantánea de 2022), PyYAML falla 73 de 402 casos. Y 2024-01-01 es una fecha en PyYAML pero un string en js-yaml 5, mientras que 1_000 es 1000 en PyYAML y un string en js-yaml.

En TOML, el problema es otro: hay tres formas de anidar tablas ([server] con port = 8080, server.port = 8080 y server = {port = 8080}) y las líneas posteriores pueden modificar tablas anteriores. La especificación cita CVE-2026-44244, donde un atacante capaz de inyectar un salto de línea en un valor pudo agregar una sección [core] dentro de .git/config para lograr ejecución de código. SOML cierra esa puerta: los objetos y arrays previos quedan cerrados.

SOML vs JSON vs YAML vs TOML: qué cambia en la práctica

La comparación que hace el propio proyecto deja claras las diferencias de diseño:

Comentarios: SOML admite # y también bloques /* */. JSON no admite ninguno.
Llaves en el nivel superior: SOML no las necesita; JSON las exige.
Comas entre ítems en líneas separadas: SOML no las requiere; JSON sí.
Claves sin comillas: SOML las permite, incluso con guiones y dígitos.
Entero y float separados: SOML sí; JSON no.
Fechas y duraciones: SOML tiene fecha, instante y duración como tipos propios; TOML tiene cuatro tipos de fecha y hora pero ninguna duración.
Claves duplicadas: en SOML son un error; en JSON queda a criterio del parser.
Forma canónica: SOML la define, de modo que valores iguales producen los mismos bytes para hashing y firma. YAML solo la define para escalares.

Un detalle práctico: SOML usa : como separador, así que un JSON escrito a mano suele ser SOML válido. Eso baja la barrera de entrada para equipos que ya viven en el mundo de JavaScript.

¿Qué significa esto para tu startup?

Si tu producto depende de archivos de configuración —y casi cualquier SaaS lo hace—, la ambigüedad de tipos es un riesgo silencioso. Un version: 3.10 que se convierte en 3.1, o un country: no que se vuelve false, puede romper un despliegue sin que nadie toque una línea de código.

Tres acciones concretas que puedes tomar esta semana:

Audita tus archivos YAML y TOML buscando valores que puedan cambiar de tipo: versiones con dos puntos decimales, códigos postales con ceros a la izquierda, valores como no, on o ~. Si los encuentras, fuérzalos a string con comillas.
Revisa cómo cargas la configuración. La especificación recuerda que en PyYAML safe_load es opt-in y que los alias pueden habilitarse incluso en loaders llamados "seguros". Si tu pipeline lee config de terceros, vale la pena confirmar qué loader usas.
Prueba SOML en un proyecto nuevo, no en producción. Al ser un borrador con librerías "nuevas, en pocos lenguajes", tiene sentido experimentar primero en una herramienta interna o un servicio nuevo, y no migrar toda tu infraestructura.

Un formato joven, con una comunidad activa

SOML no llega solo como especificación. El repositorio lista implementaciones en JavaScript (la de referencia), Swift, Rust, Python, Go, Ruby, C++, C, C#, Java, Kotlin, Dart, PHP y Zsh, además de plugins para ESLint y Prettier, resaltado de sintaxis para highlight.js y Prism, y una app de macOS para ver y editar archivos SOML. La especificación se publica bajo licencia MIT y puede implementarse libremente sin referenciarla.

El punto que más debería importar a un equipo técnico es la suite de conformidad de casi 1.000 casos, compartida entre implementaciones. Es la respuesta directa al problema de fondo: que dos parsers lean el mismo archivo de la misma manera. Si esa promesa se sostiene, SOML podría convertirse en una alternativa seria para configuraciones críticas. Si no, quedará como un experimento interesante más.

No se encontraron datos adicionales verificables en la búsqueda web sobre adopción, usuarios o respaldo de terceros: por ahora, toda la información disponible proviene de la especificación oficial del proyecto.