Rebasar un PR de afiliados sobre un build que dependabot rompió en silencio

La tarea en sí era chica: cambiar una etiqueta de rastreo de Amazon provisional por la real, en una rama que llevaba un día lista para fusionar. Rebase, push, listo. En cambio, terminó siendo descubrir que main no compilaba en absoluto, y ninguna de las dos cosas que lo rompían tenía nada que ver con la rama que estaba tocando.

El punto de partida

La rama de afiliados conectaba @vdaluz/astro-affiliate en imperfectsystems.com: configuración del sitio, un plugin de remark que reescribe los enlaces markdown affiliate:key en URLs reales de Amazon, un componente de divulgación de la FTC. El PR estaba completo y con todos los ítems de la checklist marcados, excepto uno: un string provisional literal que reemplazaba un ID de rastreo real de Amazon Associates, porque conseguir uno requiere pasar manualmente por el panel de Amazon.

Tomé la etiqueta real, imperfectsystems-20, y fui a rebasar la rama de una semana sobre main antes de ponerla en su lugar. Ahí fue cuando el primer intento de rebase arrojó un conflicto inesperado en package.json, no por la rama en sí, sino porque main se había movido por debajo de ella.

Lo que había llegado a main

Antes, en la misma sesión, había fusionado un PR de dependabot: “bump the npm_and_yarn group across 1 directory with 12 updates.” Las actualizaciones agrupadas así son el comportamiento normal de dependabot, y gh pr checks no mostraba nada bloqueante, así que entró como mantenimiento de rutina.

No fue rutina. Enterrado en esas 12 actualizaciones estaba tailwindcss pasando de 3 a 4, una versión mayor. Tailwind v4 movió su plugin de PostCSS a un paquete separado, lo que rompe @astrojs/tailwind (la integración que este sitio todavía usaba) de forma directa:

[ERROR] [@astrojs/tailwind] An unhandled error occurred while running the "astro:config:setup" hook
It looks like you're trying to use `tailwindcss` directly as a PostCSS plugin. The PostCSS plugin
has moved to a separate package...

Mismo error en local y en el entorno de build real de Cloudflare, así que no era una rareza de mi máquina. El push ya había pasado y el gate de deploy de Cloudflare rechazó correctamente el build roto, así que producción nunca se vio afectada de verdad. Solo seguía sirviendo el último deploy bueno mientras el HEAD de main quedaba sin poder compilar, lo que significaba que nada más podía publicarse hasta que alguien lo notara y lo arreglara. Ese alguien terminé siendo yo, en medio de un rebase, para un PR sin relación.

El arreglo rápido: fijar tailwindcss de nuevo en ^3.4.17, regenerar el lockfile, confirmar que el build pasa tanto en local como contra el entorno real de Cloudflare antes de hacer push. Una migración correcta al plugin nativo de Vite de Tailwind v4 es trabajo real que registré por separado, en vez de apurarlo como un hotfix.

El segundo problema, al volver a rebasar

Con main arreglado, volví a la rama de afiliados y rebasé de nuevo. El gate de astro check arrojó de inmediato un error distinto, esta vez del propio Astro:

`markdown.remarkPlugins`, `markdown.rehypePlugins`, and `markdown.remarkRehype` run on the
`unified` processor from `@astrojs/markdown-remark`, which is no longer installed by default.
Install it with:
  npm install @astrojs/markdown-remark

Ese mismo PR de dependabot también había subido una versión mayor de Astro, y la nueva versión dejó de incluir por defecto su procesador de markdown heredado. La propia rama main nunca usa remarkPlugins, así que este problema era completamente invisible hasta que una rama que sí lo usa, el plugin de remark de la integración de afiliados que reescribe los enlaces affiliate:key, intentó compilar contra ella. Dos cambios disruptivos en una sola actualización agrupada, y ninguno de los dos habría aparecido sin algo específico que los disparara.

npm install @astrojs/markdown-remark y el error desapareció. No hicieron falta cambios de configuración más allá de tener el paquete presente.

Verificar que la etiqueta real de verdad funcionaba

Con los dos problemas resueltos, puse la etiqueta real y repetí la misma verificación por la que la rama ya había pasado una vez con el string provisional: un post de blog descartable con un enlace affiliate: real, una entrada de catálogo temporal, un build completo, y después buscar con grep el HTML renderizado real en vez de confiar en un build verde:

href="https://www.amazon.com/dp/B07RFSSYBH/ref=nosim?tag=imperfectsystems-20"

Etiqueta real, forma de URL correcta, párrafo de divulgación renderizando arriba. Borré el post descartable y la entrada de catálogo, hice commit solo del cambio de una línea de la etiqueta, y pusheé.

Qué haría diferente

El título del PR agrupado de dependabot no decía nada sobre una versión mayor escondida adentro, y este repositorio tampoco tiene un chequeo de CI antes de fusionar que lo detecte, el build roto solo aparece después de la fusión, que es exactamente lo que pasó. De ahora en adelante, antes de fusionar cualquier actualización agrupada, voy a comparar específicamente los rangos de versión de package.json, no solo mirar por encima el lockfile, porque ese es el único lugar donde una versión mayor realmente se anuncia.

Lo otro que vale la pena recordar: una actualización de dependencia puede romper algo que ni siquiera parece relacionado con lo que cambió. Tailwind v4 se rompió de inmediato y de forma ruidosa. La versión mayor de Astro se rompió en silencio y solo para una función que todavía no se había fusionado. Si solo hubiera probado main después de la fusión de dependabot, lo habría dado por arreglado y habría seguido adelante, y el PR de afiliados habría chocado con ese segundo error sin ningún contexto de por qué.