composer outdated y composer why-not: qué bloquea la actualización a Laravel 11

Hola, bienvenido. En esta lección vamos a preguntarle a Composer qué nos impide instalar Laravel 11, antes de cambiar nada en composer.json. composer outdated nos dice qué paquetes tienen versiones nuevas que podríamos instalar en este momento, y composer why-not nos dice qué impide instalar una versión concreta y qué paquete lo bloquea. Con los 2 vamos a preparar el plan de la actualización, y veremos por qué composer outdated no enseña Laravel 11.

Antes de actualizar, lo habitual es preguntar qué paquetes tienen versiones nuevas. --direct limita la lista a los paquetes que están en nuestro composer.json, sin las dependencias de las dependencias, que no nos interesan ahora. Esta es la salida el 21 de octubre de 2026 (las versiones más nuevas cambiarán cuando lo lances tú):

Fíjate en lo que falta. No dice nada de laravel/framework, que tiene 3 versiones major por delante, ni de Sanctum, ni de Breeze, ni de Pest, ni de Collision. Solo lista 5 paquetes con una versión major nueva (doctrine/dbal 4, Guzzle 8, Tinker 3, Livewire 4 y Spatie Permission 6) y a Larastan, que aparece por estar abandonado, no porque tenga una versión nueva. Viendo solo esta salida, Laravel 10 parecería la última versión.

¿Por qué? Porque Composer se ejecuta dentro del contenedor, y outdated solo enseña las versiones que se pueden instalar con su versión de PHP, que es la 8.1. Laravel 11, Sanctum 4, Breeze 2, Collision 8 y Pest 3 exigen PHP 8.2 o superior, así que para Composer no existen mientras el contenedor siga en 8.1. Los 5 paquetes que sí lista tienen versiones major nuevas que siguen admitiendo PHP 8.1, y por eso aparecen. En la siguiente lección, cuando el contenedor esté en PHP 8.2, repetiremos este mismo comando y la lista será otra.