Formateador de JavaScript

Prettier no es meramente la inspiración para la salida de formateo de esta herramienta — es el propio paquete Prettier, descargado y ejecutado en tu navegador en lugar de a través de Node en un servidor, así que el resultado es idéntico byte por byte a lo que produciría ejecutar `npx prettier` localmente con la misma configuración. Esa distinción importa porque el formateo de JavaScript es genuinamente difícil de aproximar: hacerlo bien requiere analizar completamente el lenguaje, no compararlo con patrones, y un formateador que solo aproxima el comportamiento de Prettier discrepará con la configuración real de Prettier de un proyecto exactamente en los casos extremos donde importa — dentro de un decorador, un tipo genérico complejo, o una expresión JSX inusual.

JavaScript contiene varias construcciones que hacen que un enfoque simple de contar llaves y punto y coma falle directamente. Los literales de plantilla pueden contener texto arbitrario entre acentos graves, incluyendo caracteres que parecen exactamente código — `` `function() { return "not real code"; }` `` es un solo valor de cadena, no tres sentencias, y un formateador que no rastrea los límites de los literales de plantilla lo malinterpretará. Los literales de expresión regular son peores: `/{}/` contiene caracteres que parecen llaves pero forman parte del propio patrón de la expresión regular, no sintaxis estructural. La inserción automática de punto y coma añade una tercera capa de dificultad, ya que JavaScript permite omitir puntos y coma en muchos contextos e infiere dónde termina una sentencia según reglas que un formateador ingenuo basado en líneas no tiene forma de replicar correctamente. Analizar realmente el lenguaje en un árbol de sintaxis adecuado, como hace Prettier, es lo que evita los tres modos de fallo — un formateador atajo que se equivoca aunque sea en uno de ellos en código de producción es un riesgo, no una conveniencia.

Prettier formatea código — estandariza espacios en blanco, saltos de línea, estilo de comillas y elecciones presentacionales similares — y explícitamente no comprueba si el código es correcto, seguro de tipos, o libre de errores. Un archivo con un error de tipo, una referencia a variable indefinida, o un error lógico se formatea sin quejarse siempre que sea sintácticamente válido, porque formatear y verificar tipos son preocupaciones separadas manejadas por herramientas separadas. El propio compilador de TypeScript, o un linter como ESLint, es donde se comprueba la corrección; el trabajo de esta herramienta termina en hacer que el código tenga un estilo consistente y legible.

Tabulaciones frente a espacios, comillas simples frente a dobles, punto y coma o no — ninguna de estas elecciones afecta significativamente cómo se ejecuta el código, y los desacuerdos sobre ellas solían consumir tiempo real en discusiones de revisión de código que no tenían nada que ver con la corrección. La verdadera propuesta de valor de Prettier es eliminar por completo ese debate de la mesa: un conjunto pequeño y con criterio propio de reglas de formateo aplicadas automática e idénticamente en todas partes significa que el debate se resuelve una vez, en la configuración, en lugar de repetidamente en cada pull request de ahí en adelante.

Cada opción expuesta aquí — ancho de indentación, punto y coma, estilo de comillas — refleja un ajuste real de configuración de Prettier, así que pegar código de un proyecto con un `.prettierrc` conocido e igualar esos mismos ajustes aquí reproduce exactamente lo que produciría la propia herramienta de ese proyecto, sin necesidad de instalar nada localmente solo para comprobar cómo se formatearía un fragmento.