Tarjetas OG de código abierto, y el espacio que no estaba

La sección de Código abierto de este sitio se publicó sin tarjetas sociales propias. Cada enlace hacia ella caía en la imagen OG genérica del sitio, la misma imagen sin importar si se compartía el índice o la página de detalle de un paquete específico. La solución fue generar una tarjeta real por página, usando el propio generador de tarjetas OG del sitio para hacerlo. Básicamente, usar el propio producto.

El diseño ya estaba ahí

El sitio ya tenía un diseño de tarjeta tipo ventana de terminal para su imagen OG por defecto: texto con resplandor verde, un prompt de zsh falso, una barra de título estilo macOS. No hacía falta un nuevo lenguaje visual, solo una nueva línea de comando. La tarjeta del índice recibió $ ls @vdaluz/*. Cada tarjeta de paquete recibió $ npm install @vdaluz/<name>, con el nombre del paquete intercambiado tanto en el comando como en la barra de título.

Conectarlo fue mecánico: dos funciones de marcado nuevas, unas líneas más en el script de prebuild que ya genera la tarjeta por defecto, la tarjeta de Deep Cut Atlas y las tarjetas de las entradas del blog. Cinco PNG nuevos, cinco props image nuevas en los archivos de página correspondientes. La expectativa era que ese fuera todo el trabajo.

El espacio que no estaba

Abrí los PNG generados para revisarlos a simple vista antes de confirmar los cambios, porque que un build pase no significa que el diseño se vea bien. La tarjeta de astro-opt-in-analytics mostraba npm installavdaluz/astro-opt-in-analytics, “install” y el nombre del paquete pegados sin espacio, y la “a” de “@vdaluz” se renderizaba sin que se viera la @ porque ambos se superponían. La tarjeta del índice tenía lo mismo: lsavdaluz/* en vez de ls @vdaluz/*.

La primera sospecha fue un error de tipeo en el propio marcado. No lo era. El espacio estaba ahí, en el código fuente, un carácter literal entre “install” y el span con estilo que contenía el nombre del paquete. Después revisé la tarjeta existente por defecto, la que llevaba todo este tiempo en producción, y encontré el mismo error ya publicado: ”./run—software” en vez de ”./run —software”, “ImperfectSystems” en vez de “Imperfect Systems.” Nadie lo había notado, porque nadie había mirado tan de cerca una tarjeta que ya funcionaba lo bastante bien como para no llamar la atención.

La causa real: satori-html colapsa un nodo de texto con espacio en blanco al final cuando está justo antes de un <span> con estilo en línea dentro de un contenedor flex. Un carácter de espacio literal en el marcado no sobrevive si el siguiente elemento hermano tiene estilo. La solución fue dejar de depender de que ese espacio existiera y darle al span siguiente un margin-left explícito. Una vez hecho eso, ambas tarjetas nuevas se renderizaron exactamente como estaban diseñadas.

Qué hice con esto

Lo corregí de inmediato en los dos archivos nuevos y abrí un ticket aparte de baja prioridad para las tarjetas preexistentes, la por defecto y las de las entradas del blog, ya que ese error era anterior a este trabajo y arreglarlo ahí no era tarea de este ticket. Después, más tarde en la misma sesión, volví sobre eso y también lo corregí. Para ese momento el patrón y la solución ya se entendían, así que fue un cambio de cinco minutos en vez de una investigación nueva. Registrarlo aparte primero, y resolverlo después en un momento libre, mantuvo honesto el alcance original en vez de dejarlo crecer en silencio hacia “tarjetas OG, día dos.” También dejé anotada la rareza de satori-html en las notas de errores conocidos del paquete compartido, porque va a afectar al próximo diseño de tarjeta que reutilice este patrón de layout.

Lección

“El build pasó” y “el archivo existe” no son la misma afirmación que “la cosa se ve bien.” Podrían haberse publicado cinco tarjetas con un error de renderizado sin que nadie se diera cuenta, porque nada en el pipeline, astro check, el build, ni siquiera la existencia del archivo en disco, inspecciona lo que realmente hay dentro de una imagen generada. Lo único que lo detectó fue abrir el PNG, de la misma forma en que abrir los píxeles reales fue lo que corrigió mi modelo mental más de una vez.