¿Por qué Prettier es roca sólida?

Artículo original ↗ Discusión en Hacker News ↗

Prettier, el popular formateador de código para JavaScript/TypeScript, es elogiado por su fiabilidad y por la forma en que estandariza el estilo entre equipos, reduciendo las discusiones estériles sobre el formateo y facilitando las revisiones de código. Los comentaristas atribuyen su robustez a una mezcla de algoritmos sólidos, amplia cobertura de pruebas y respaldo corporativo, pero también señalan inconvenientes reales: problemas de rendimiento frente a herramientas más nuevas basadas en Rust, cambios de comportamiento o errores en casos límite (especialmente en HTML y lenguajes de plantillas) y una configurabilidad limitada que puede frustrar a los usuarios. El debate se amplía hacia si los autoformateadores estrictos y opinativos son un beneficio neto para la práctica de desarrollo y la colaboración en equipo, o si fomentan una dependencia excesiva y una complejidad innecesaria.

Por qué Prettier es visto como “roca sólida”

  • Muchos atribuyen su robustez menos a un único algoritmo ingenioso y más a pruebas extensas, mucho trabajo sobre casos límite y mantenimiento a largo plazo.
  • Un tema recurrente: el respaldo corporativo (Meta) y un equipo de mantenedores con recursos hacen que la fiabilidad y la continuidad sean mucho más probables que en proyectos sostenidos solo por voluntarios.
  • Algunos argumentan que su valor real está en los equipos: elimina las discusiones estériles sobre formato en las revisiones de código y garantiza diffs consistentes.

Algoritmos, IRs y separación de líneas

  • La discusión contrasta los lenguajes funcionales de “pretty printing” (estilo Wadler) con formateadores más ad hoc / basados en búsqueda (clang-format, YAPF, dartfmt).
  • La división de líneas se menciona repetidamente como “la parte difícil”; evitar envolturas complejas, como hace gofmt, se cita como una gran simplificación.
  • Un autor de formateadores explica que reescribió su IR porque la indentación y los saltos de línea interactúan de formas no locales y combinatorias.
  • Hay debate sobre si los enfoques funcionales estilo PPL son lo bastante expresivos para lenguajes complejos del mundo real.

Errores, roturas y conteos de incidencias

  • Se citan varios errores concretos de Prettier: ruptura del DOCTYPE XHTML, movimiento de comentarios ignore de TypeScript, alteración de funciones CSS anidadas, problemas con HTML de Django y Astro, y fallos de larga data.
  • Más de 1k incidencias abiertas se interpretan por algunos como evidencia de complejidad o de la “chapuza” del ecosistema de lenguajes; otros lo ven como algo normal en herramientas muy usadas.
  • Prettier ha publicado formateos que cambian el comportamiento en versiones de parche (por ejemplo, alrededor de JSONC/tsconfig), lo que lleva a debatir qué cuenta como un “cambio de ruptura” y con qué rigor debería seguirse el versionado semántico.

Rendimiento y alternativas

  • Hay quejas de que Prettier es notablemente más lento que herramientas como ocamlformat, ruff y Biome basado en Rust; algunos usuarios cambian principalmente por velocidad.
  • Dprint, Biome, golines y varios linters/formateadores (Black, isort, reorder-python-imports, ESLint Stylistic, standardjs) se mencionan como alternativas o complementos.

Filosofía del formateo

  • Algunos ven el autoformateo como esencial y liberador: el código se escribe en una especie de “taquigrafía” flexible y se limpia al guardar.
  • Otros consideran que Prettier es mediocre, sobrevalorado o demasiado opinativo, y sostienen que el formateo está sobrevalorado en comparación con la lógica.
  • Existe tensión entre herramientas estrictas y no configurables (Black, los valores por defecto de Prettier) y equipos que quieren más control sobre el estilo y los diffs.
  • Algunos temen que la dependencia fuerte de formateadores perjudique el sentido de la estética del código en desarrolladores junior; otros consideran que esa es una habilidad de poco valor frente a competencias de nivel superior.