Dependencias inexistentes y sustitución de paquetes

Cuando un modelo no recuerda el nombre exacto de una biblioteca, puede inventar uno que suena correcto: une dos palabras del dominio, añade el país o un sufijo habitual. El nombre no existe, pero parece tan razonable que quien lo lee no lo pone en duda. Hoy la instalación fallaría; el problema empieza mañana.

En los registros públicos de paquetes cualquiera puede publicar con un nombre libre. Si el mismo nombre inventado aparece una y otra vez en las respuestas de los asistentes, alguien puede registrarlo y esperar a que lleguen instalaciones. Quien instala sin mirar recibe el código de un desconocido, con los permisos de su equipo o de su integración continua. Es la misma familia de riesgo que los nombres casi idénticos a uno popular, pero aquí el nombre lo sugiere el propio asistente.

El primer filtro de cualquier dependencia nueva es comprobar que existe, en el registro del que se va a instalar. Un PR que agrega un paquete inexistente no debería poder fusionarse: o el autor no lo instaló nunca, o lo tomó de una sugerencia sin comprobar.

Cruza las dependencias que agrega el PR con la consulta al registro público.

Que un paquete exista no basta. Hay señales que separan una biblioteca con historia de una recién aparecida: la fecha de la primera publicación, cuántas versiones tiene, si la cuenta que la publica se creó el mismo día y cuántas descargas suma. Ninguna prueba por sí sola que el paquete sea malo, pero juntas, y con una fecha posterior a la sugerencia del asistente, son motivo para detener el PR.

Compara la fecha de la conversación con el asistente con los datos del registro.

Muchas empresas publican paquetes propios en un registro interno. Si el instalador consulta también el registro público y elige la versión más alta entre los dos, basta con que alguien publique afuera un paquete con el mismo nombre y un número de versión mayor para que la compilación tome el de afuera. Se conoce como confusión de dependencias, y no hace falta que el asistente se equivoque: basta con que sugiera el nombre interno correcto en un entorno mal configurado.

Lee la lista de paquetes internos, el registro público y la regla del instalador.

Los tres hallazgos tienen algo en común: el instalador acepta cualquier nombre de cualquier lugar. Revisar a mano cada PR ayuda, pero depende de que alguien se acuerde. El control de fondo está en la cadena de instalación: de dónde puede venir un paquete, qué nombres están permitidos y qué huella exacta se espera de cada uno.