Saltar al contenido
Development

Destacando los paquetes compartidos de los que este sitio depende en silencio

Por Victor Da Luz
astromarketingdev-logsite

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

Development

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.

Leer