Confieso que, hace varios años, cuando recién empezaba a trabajar con Laravel, desinstalar un paquete era un verdadero cacho para mí. Yo iba directo a borrar la línea del composer.json, eliminaba la carpeta en vendor/, y después me extrañaba por qué seguía teniendo errores o archivos fantasma rondando por ahí. De hecho, no entendía por qué a veces un simple composer update no terminaba de limpiar todo. Era una sobreingeniería de mi parte, al intentar forzar algo que Composer ya tenía resuelto.
La forma directa y elegante de decirle a Composer que ya no quieres un paquete es con un comando específico. Esto es lo primero y más importante, y lo que muchos olvidan o hacen mal:
composer remove vendor/packageEste comando hace tres cosas clave:
- Elimina la entrada del paquete de tu archivo
composer.json. - Actualiza el archivo
composer.lockpara reflejar este cambio. - Borra la carpeta del paquete de tu directorio
vendor/.
Con eso, Composer ya no considerará ese paquete como una dependencia de tu proyecto. Pero ojo, esto es solo la mitad de la historia, especialmente cuando hablamos de Laravel. Un paquete Laravel no solo son sus archivos en vendor/, sino también las configuraciones que pudo haber publicado o las referencias que dejaste en tu código. Es aquí donde muchos se quedan cortos, y donde un cliente me consultó una vez por errores que venían de paquetes que "ya no usaba".
Para una desinstalación completa en Laravel, después del composer remove, tenés que hacer una limpieza manual:
- Eliminar Service Providers: Revisá tu archivo
config/app.phpy borrá cualquier referencia al Service Provider del paquete en el array'providers'. - Borrar Alias de Clases: Igual que lo anterior, en
config/app.php, sacá cualquier alias que el paquete pudiera haber registrado en el array'aliases'. - Configuraciones Publicadas: Si el paquete publicaba sus archivos de configuración (por ejemplo, con
php artisan vendor:publish), vas a tener un archivoconfig/packagename.phpque tenés que borrar a mano. - Archivos de Migración: Si el paquete incluía migraciones y las ejecutaste, podrías considerar hacer un
rollbacko simplemente asegurarte de que sus tablas no queden huérfanas en tu base de datos (y luego borrar los archivos de migración si fueron publicados). - Assets Públicos: Algunos paquetes publican CSS, JS o imágenes en el directorio
public/. Buscá y eliminá esos archivos o carpetas. - Referencias en el Código: Obviamente, quitá cualquier llamada,
use, o inyección de dependencia que tu código hiciera a clases de ese paquete. Esto es sentido común, pero a veces se olvida.
Aunque composer remove suele manejar el autoloading, si sentís que algo no cuadra o el autoloader quedó "medio loco", no está de más ejecutar un composer dump-autoload al final. Esto regenera el mapa de clases para asegurarse de que todo esté en orden.
Si hay algo que aprendí tarde es que las cosas que parecen triviales, como desinstalar un paquete, si no se hacen bien, te pueden generar más problemas que el paquete mismo. Ojalá alguien me lo hubiera explicado así de completo cuando empecé, me habría ahorrado varios dolores de cabeza y horas de debugging.