Mantener un proyecto frontend no se trata solo de que funcione para el usuario final. La forma en que un equipo de ingeniería escribe, lee y colabora sobre el código determina la velocidad y calidad con la que se entrega producto. Aquí es donde entra un concepto fundamental: el developer experience, es decir, qué tan fluido y eficiente resulta el proceso de desarrollo para quienes construyen el software.
¿Por qué el developer experience impacta en la entrega de producto?
Aunque el user experience siempre será la prioridad —porque el objetivo final es impactar positivamente a los clientes del negocio—, el developer experience es un facilitador directo del delivery [0:26]. Entre más sencillo sea mantener y desarrollar dentro de un proyecto, más rápido y con mayor calidad se entrega producto.
Para lograrlo existen múltiples prácticas que aseguran un estándar de calidad en el equipo:
- Unit testing e integration testing antes de lanzar a producción.
- Linters que analizan prácticas de seguridad y accesibilidad.
- Formateadores de código como Prettier.
De todas estas herramientas, Prettier es una de las más sencillas de implementar y genera un impacto inmediato en la cooperación del equipo [1:30].
¿Qué problema resuelve Prettier en un equipo de ingeniería?
Seguramente has visto discusiones entre programadores sobre si usar tabs o espacios, comillas simples o dobles, punto y coma al final de línea o no. Estas discusiones son innecesarias cuando existe un formateador automatizado [1:45]. Si un desarrollador hace commits cambiando el estilo de indentación y otro revierte esos cambios, se generan commits sin valor real.
Prettier toma código desordenado —o simplemente escrito con criterios distintos— y lo transforma en un formato estándar. Por ejemplo, una función con parámetros amontonados en una sola línea se reorganiza con saltos de línea por cada parámetro, facilitando la lectura [3:05]. El HTML también se reestructura de forma legible.
¿Se puede personalizar la configuración de Prettier?
Sí. Aunque Prettier viene con valores preconfigurados que funcionan para la mayoría de equipos, es posible ajustar opciones como:
- El tamaño de indentación: dos, tres o cuatro espacios según lo que decida el equipo.
- El ancho máximo de línea (print width): un valor como ochenta evita el scroll horizontal excesivo [3:50].
- El uso de comillas dobles o simples.
Un valor de línea demasiado bajo, como diez, genera saltos de línea excesivos. Uno demasiado alto, como doscientos, deja el código demasiado ancho. El estándar habitual ronda los ochenta caracteres.
¿Cómo se integra Prettier en un proyecto de Astro?
Desde la documentación de Astro se indica la instalación de Prettier junto con un plugin específico para el framework [4:40]. Después se crea un archivo de configuración llamado .prettierrc con las reglas estándar del proyecto.
En el package.json se crean dos scripts clave:
format: ejecuta Prettier con la bandera --write, que corrige automáticamente todos los problemas de formato.format:check: solo reporta los problemas sin modificar archivos [5:40].
Al ejecutar format:check, la terminal muestra advertencias (warnings) sobre archivos que no cumplen el estándar. Al ejecutar format, Prettier aplica las correcciones directamente. En la práctica, los cambios más comunes incluyen unificar comillas, dividir líneas largas y organizar atributos HTML con saltos de línea para mejorar la lectura [6:50].
¿Cómo automatizar el formato para que ningún desarrollador lo olvide?
Tener el script disponible no garantiza que todos lo ejecuten. Depender de que cada ingeniero recuerde correr el comando manualmente es una mala práctica [8:15]. La solución es llevar la verificación al flujo de integración continua.
Con GitHub Actions se puede configurar que, por cada pull request, se ejecute automáticamente el comando format:check [8:40]. Si el código enviado no cumple con el formato estándar, el pull request se rechaza de forma automática. El desarrollador recibe un aviso claro: el formato está roto y debe corregirlo antes de que su contribución sea aceptada.
Este mismo enfoque aplica para otras validaciones automatizadas:
- Reglas de seguridad y buenas prácticas.
- Pruebas unitarias (unit tests).
- Análisis de accesibilidad.
Cuando todas las automatizaciones pasan correctamente, el pull request avanza a una revisión más profunda, ya sea por un humano o por herramientas de AI [9:20]. Las revisiones mecánicas —como el formato— quedan delegadas al proceso automatizado, liberando al equipo para enfocarse en lo que realmente importa.
Si ya usas Prettier en tus proyectos, ¿qué otras automatizaciones has integrado en tu flujo de trabajo? Comparte tu experiencia.
