El árbol y el archivo de bloqueo

El archivo de dependencias directas del equipo dice cosas como «cualquier versión de la 2.5 en adelante, pero menos de la 3». Es un rango, no una versión. Si la cadena resuelve ese rango cada vez que compila, el mes que viene puede instalar una versión que hoy ni existe, y dos despliegues del mismo commit llevarían componentes distintos. Por eso existe el archivo de bloqueo: la resolución ya hecha, con la versión exacta de cada paquete, directo o transitivo. La cadena instala lo que dice el bloqueo, y una versión nueva solo entra cuando alguien regenera el archivo y el cambio se ve en la revisión.

El bloqueo es lo que convierte «lo que pedí» en «lo que se despliega», y es el documento que un análisis de composición debería leer.

En el archivo de bloqueo cada línea trae un comentario: «directa» si el equipo la pidió, o «via» seguido de quien la trae. Una transitiva puede venir de otra transitiva, y entonces hay que seguir la cadena hasta llegar a una directa. Es el mismo trabajo que hace un desarrollador cuando pregunta «¿por qué tenemos esto?». La directa final es la que se puede subir o cambiar; la transitiva no se toca desde el archivo de entrada del equipo.

Seguir esa cadena es lo primero que se hace cuando aparece un aviso sobre un componente que nadie recuerda haber elegido.

Cuando una transitiva tiene un fallo, el equipo no la declaró y por tanto no hay una línea suya que editar. Hay dos caminos. El primero, y el preferido: subir la directa a una versión que ya arrastre la transitiva corregida. El segundo, cuando esa versión no existe todavía: añadir una restricción explícita sobre la transitiva en el archivo de entrada, con un comentario que diga por qué está ahí y cuándo se puede quitar, y regenerar el bloqueo. Editar a mano solo el archivo de bloqueo no sirve: la próxima resolución lo deshace.

Una restricción sin motivo escrito se convierte en deuda que nadie se atreve a borrar.

El informe del árbol cuenta la profundidad: las directas están en la 1; lo que traen, en la 2; lo que traen esas, en la 3. Cuanto más hondo está un componente, menos probable es que alguien del equipo lo conozca, y más tarda en llegar la corrección, porque tiene que subir cada eslabón de la cadena. No significa que sea menos peligroso: un fallo a profundidad 3 se despliega igual.

Mirar el árbol con su profundidad te dice dónde está lo que nadie vigila.