Destacando los paquetes compartidos de los que este sitio depende en silencio
El widget de GitHub en la portada de este sitio siempre mostró tarjetas de repos fijados obtenidas en vivo de una API de estadísticas: trello-extractor, programming-problems, homelab-tools, astro-blog. Eso está bien para proyectos personales, pero entierra la historia más interesante. Tres de los paquetes que construí, astro-blog, astro-affiliate, astro-opt-in-analytics, no son proyectos paralelos. Son infraestructura. Cada sitio de la familia vdaluz.com corre sobre ellos en producción en este momento.
Por qué una subsección nueva en vez de solo agregar a la lista fijada
Las tarjetas autogeneradas traen las estadísticas que sea que devuelva un servicio de terceros: estrellas, lenguaje, una descripción de GitHub de una línea. Ese es el argumento equivocado para estos tres. A nadie le importa que astro-affiliate tenga cero estrellas. Lo que importa es que es el resolvedor de enlaces de afiliados por el que pasa cada post de este sitio y de vdaluz.com. Así que agregué una subsección “Paquetes compartidos” arriba del bloque existente, con presentaciones escritas a mano tomadas directamente de la descripción del propio package.json de cada paquete en vez de parafraseadas de memoria, y dejé el bloque autogenerado intacto debajo.
export const sharedPackages: SharedPackage[] = [
{
name: 'astro-blog',
pitch: 'Shared Astro blog components, related-posts scoring, schema factory...',
href: 'https://github.com/vdaluz/astro-blog',
},
// ...
];
El problema: verificar cambios de UI para un chequeo que no existe
Las convenciones propias de este repo piden correr npm run a11y en cualquier cambio de UI. Fui a correrlo y descubrí que no existe tal script acá, existe en vdaluz.com, no en este sitio. Había asumido que las herramientas se compartían en toda la familia de la misma forma que los paquetes. No es así.
En vez de saltarme el chequeo, corrí npx @axe-core/cli directamente contra un servidor local astro preview:
npx @axe-core/cli http://localhost:4322/ --tags wcag2a,wcag2aa
0 violations found!
Eso funciona bien como algo puntual, pero no es algo que la siguiente persona (o mi próximo yo) vaya a acordarse de correr. Registré un seguimiento para de verdad agregar el script acá en vez de dejarlo como una solución manual que solo existe en el historial de shell de esta sesión.
Resultados
astro check, prettier --check y astro build pasan todos limpios. Tomé una captura de la vista previa renderizada para confirmar que la subsección nueva quedó donde debía, con un estilo consistente con el resto del tratamiento de tarjetas .glass de la página. Cero violaciones de a11y en la portada.
Lección
“Este repo sigue las mismas convenciones que sus hermanos” es una suposición que vale la pena verificar, no confiar a ciegas. Los cuatro sitios de Astro de esta familia comparten un stack, pero no todas las herramientas llegaron a cada repo, y la brecha no aparece hasta que se intenta correr el chequeo de verdad.
Lecturas relacionadas
El texto de la landing page que competía en la categoría equivocada
La página de marketing vendía el seguimiento de lanzamientos nuevos, terreno propio de un competidor establecido, mientras el comentario de documentación del view model tenía el verdadero mensaje desde siempre.
Capturas de pantalla para una app sin simulador
MusicKit no devuelve nada en el simulador, así que las capturas de marketing salieron del servicio simulado que la app ya tenía, más las portadas reales de la API de búsqueda de iTunes.
Los pills de filtro existían, solo que no donde alguien pudiera encontrarlos
Vistas filtradas por proyecto con una linda barra de navegación de pills, accesibles solo desde las tarjetas de la portada. El índice principal /blog, donde realmente aterriza todo el mundo, no tenía ninguna forma de entrar.