Bun 1.4 Parsea JSON5, JSONL y YAML de Fábrica: Fin del Drama de los Comentarios en JSON

JSON es terrible para configuración y todo el mundo lo sabe

Cuando analizamos el RFC 8259 actualizado ya lo decíamos: JSON no tiene comentarios, no admite trailing commas y exige comillas en las claves. Para APIs es perfecto; para un tsconfig.json que tiene que explicarse a sí mismo, es un desastre.

Por eso existen JSON5, JSONC, YAML y TOML. La noticia: Bun 1.4 los soporta de serie, con APIs nativas — Bun.JSON5, Bun.JSONL, Bun.YAML — escritas en Zig y a la velocidad a la que Bun nos tiene acostumbrados con JSON.parse.

---

Qué aporta cada formato

JSON5: JSON que admite humanos

const config = Bun.JSON5.parse(`
{
  // esto es un comentario, por fin
  'puerto': 3000,
  plugins: [
    'auth',
    'cache',  // trailing comma sin drama
  ],
}`);

Comillas simples, claves sin comillas, comentarios y trailing commas. Todo lo que tsconfig.json lleva años haciendo de facto con JSONC, pero con spec y parser oficial.

JSONL/NDJSON: una línea, un objeto

El formato de facto para logs, exports masivos y datasets de LLMs. Bun lo trata como ciudadano de primera:

for await (const row of Bun.JSONL.stream(file.stream())) {
  // cada línea del archivo ya es un objeto parseado
}

Si alguna vez hiciste text.split('\n').map(JSON.parse), sabes que se rompe con líneas vacías y es una bomba de memoria. Esto lo resuelve bien.

YAML: el estándar de facto de la configuración

Kubernetes, GitHub Actions, Docker Compose: la mitad de tu repo ya es YAML. Bun.YAML.parse() lo parsea sin traerte js-yaml como dependencia.

---

¿Y esto por qué importa?

1. Sin dependencias: cada parser que metías por npm era una dependencia que auditar, actualizar y, como vemos cada semana, defender de supply chain attacks.
2. Rendimiento nativo: parsear un YAML grande para cargar config deja de ser una penalización de arranque.
3. Validación previa gratis: antes de commitear un JSON5 o un JSONL enorme, pásalo por nuestro formateador JSON para verificar la estructura — JSON5 estricto de datos sigue siendo JSON válido en su núcleo.

---

¿Cambio mis configs ya?

• Si el proyecto vive en Bun: sí, JSON5 para configs internas y JSONL para exports/logs es la opción sensata.
• Si compartes configs con Node u otros runtimes: quédate en JSON estándar y deja JSON5 para lo estrictamente local — nuestro validador JSON te dirá en dos segundos si ese archivo sigue siendo JSON puro o ya no.

El ecosistema lleva una década pidiendo "JSON con comentarios". Que un runtime lo incorpore nativamente es la señal de que, por fin, la presión ganó.