Hay mañanas en las que uno se levanta con ganas de comerse el mundo y Magento o mejor dicho en este caso Composer te recuerda, con un bofetón de realidad, que no eres tu el que manda.

Hoy vengo a contaros una de esas historias de terror que ocurren cuando un cliente decide que «ya no usamos este servicio» pero se olvida de decírselo al que pica código. Spoiler: el final incluye sudores fríos y Composer pidiéndote cosas que no tienes.

El drama: De repente, el deploy explota

Tenía yo un módulo de esos «imprescindibles» (léase: que alguien instaló en 2019 y nadie ha vuelto a mirar) configurado en el composer.json. Todo iba como la seda hasta que, de buenas a primeras, el servidor de despliegue suelta un grito agónico.

Resulta que el acceso al repositorio privado había volado. Al parecer, alguien dejó de pagar la suscripción porque el servicio ya no se usaba, pero el módulo ahí seguía, como un okupa en tu vendor.

Your GitHub credentials are required to fetch private repository metadata (https://github.com/savvycube/magento-two)

You need to provide a GitHub access token.
...

Mi historial de terminal parecía una pelea de taberna. Yo intentando entrar y GitHub pidiéndome el DNI, el grupo sanguíneo y el token de acceso de una cuenta que ya no existe. Maravilloso.

El intento fallido: «Composer, quítame esto de encima»

Después de hablar con ocho personas (incluyendo al de mantenimiento, que pasaba por allí) para confirmar que, efectivamente, no queríamos esa basura de módulo para nada, me dispongo a borrarlo con la superioridad moral de quien sabe usar la terminal:

danielnavarro@MacBook-Pro-de-Daniel src % composer remove savvycube/magento-two

savvycube/magento-two is not required in your composer.json and has not been removed

./composer.json has been updated

Running composer update savvycube/magento-two

Loading composer repositories with package information

Package "savvycube/magento-two" listed for update is not locked.

Your GitHub credentials are required to fetch private repository metadata (https://github.com/savvycube/magento-two)

¿Pero vamos a ver? ¿De verdad necesito un token de acceso también para QUITAR el módulo? Pues parece que sí. Composer intenta actualizar el estado del mundo y, al no poder leer el repo del que se quiere despedir, entra en bucle infinito de desesperación.

La solución: Cirugía a corazón abierto (y sin anestesia)

Si intentas usar la puerta principal (el comando remove) y está cerrada con llave, te toca entrar por la ventana.

Como Composer se había puesto cabezón, no quedó otra que ir a lo salvaje: editar el composer.json a mano. Sí, esa cosa que te dicen que no hagas si no sabes lo que tocas. Pues hoy tocamos.

Busqué estas líneas malditas y las borré con el odio de mil soles:

«¿Y con eso ya está?» – Preguntó el optimista

Pues no, alma cándida. Si ahora haces un composer update, corres el riesgo de que se te actualicen otros 40 módulos de Magento que no querías tocar y que la tienda empiece a lanzar fuegos artificiales (de los que queman).

La jugada maestra aquí es:

composer install

«Pero… ¿eso no tira del composer.lock?» – dirás tú con el ceño fruncido.

Pues sí y no. Cuando borras manualmente una línea del composer.json y ejecutas composer install, el sistema detecta que el .json y el .lock no están sincronizados. Al ver que falta un módulo, lo elimina del .lock y lo borra de tu carpeta vendor sin tocar ni una sola versión del resto de paquetes.

Pánico desactivado. Crisis evitada.

Así que ya sabes: si un módulo se pone digno y no te deja marcharte, borra sus huellas del JSON y haz como si nunca hubiera existido. Es cruel, pero en el desarrollo web no hay sitio para los sentimientos.