¡Hola amigos!
Bienvenidos a un nuevo curso sobre cómo actualizar una aplicación Symfony de Symfony 7 a Symfony 8.
Por suerte, las nuevas versiones de Symfony hacen que este proceso de actualización sea pan comido.
Pero todavía hay algunas cosas que hacer para que el proceso de actualización sea más suave.
Para seguir adelante, descarga el código del curso desde la parte superior de esta página, abre el directorio start
en tu IDE, y verás lo que tengo aquí.
Sigue el README para configurarlo todo, cuando estés listo, en tu terminal, ejecuta:
symfony server:start -d (la bandera -d ejecuta el servidor en segundo plano).
Haz clic en el enlace de la salida para abrir la aplicación en tu navegador.
¡Bienvenido a la Starshop!
Si has seguido nuestros cursos anteriores sobre Symfony 7, esto debería resultarte familiar.
Abajo, en la barra de herramientas de depuración web, puedes ver que estamos en Symfony 7.3.5 y PHP 8.3.30.
¿Nuestro objetivo? ¡Actualizar este chico malo a Symfony 8!
Dado que Symfony 8 requiere PHP 8.4, un buen primer paso es actualizar esta aplicación para que requiera PHP 8.4.
Al mismo tiempo, también actualizaremos a la última versión de Symfony 7.3.
Si ya has hecho estas actualizaciones importantes antes, puede que estés pensando que deberíamos actualizar
a 7.4, la última versión de Symfony 7.
Lo haremos, pero me gusta dar pequeños pasos
para evitar agobiarme con demasiados cambios a la vez.
En tu IDE, abre composer.json.
En la sección require, cambia >=8.3 por >=8.4: Esto indica a Composer
que se necesita al menos PHP 8.4 para este proyecto.
Desplázate hacia abajo y encuentra la sección config.platform.php.
Esto es lo que la CLI de Symfony utiliza para determinar qué versión local de PHP utilizar
cuando ejecutas symfony console o symfony php.
Cámbialo a 8.4: Este paso no es necesario, pero desplázate hacia abajo hasta la sección replace.
Esta es una lista de paquetes que Composer ignorará al instalar dependencias.
Puedes ver que son todos paquetes polyfill.
Son paquetes que proporcionan características de versiones más recientes de PHP a versiones más antiguas.
Como estamos en PHP 8.4, podemos añadir los paquetes polyfill para 8.3 y 8.4 a esta lista:
Ahorra unos bytes de espacio en disco y unos milisegundos de tiempo de instalación...
En nuestro terminal, confirmemos que ahora estamos utilizando PHP 8.4.
Ejecuta: symfony php --version Bien, ¡8.4.20!
Ahora, hagamos una actualización de Composer para capturar todos los cambios que hemos hecho en nuestro archivo composer.json
y actualicemos a las últimas dependencias permitidas.
Ejecuta: symfony composer update Sin errores, ¡genial!
Salta al navegador y actualiza la página...
Qué asco, esto es un error desagradable.
No se parece a los errores estándar de Symfony porque ni siquiera ha podido cargar Symfony.
Se trata de un error a nivel del autoloader de Composer.
Dice que estamos ejecutando PHP 8.3 pero nuestras dependencias requieren PHP 8.4.
¿Recuerdas que antes ejecutamos el servidor Symfony en segundo plano?
Lo ejecutamos con PHP 8.3.
Solución sencilla, reinicia el servidor con:
symfony server:stop symfony server:start -d Ahora actualiza la página...
¡Genial! Volvemos a estar operativos.
Observa en la barra de herramientas de depuración web que ahora estamos en Symfony 7.3.11 y PHP 8.4.20.
Y ahora, ¡las depreciaciones!
Cuando Symfony, o el propio PHP quieren eliminar
o cambiar una característica, no hacen el cambio sin más.
Esto podría romper montones de aplicaciones y causar muchos problemas.
En lugar de eso, marcan la función como obsoleta durante un tiempo, lo que significa que sigue funcionando
como se espera, pero activará una advertencia.
Normalmente, la advertencia explica cómo solucionar el problema
y actualizar a la nueva forma de hacer las cosas.
Symfony tiene una política de desaprobación realmente buena.
Garantizan que nada se romperá al actualizar
a una nueva versión menor, como de la 7.3 a la 7.4.
Los cambios de ruptura se producen en la versión mayor, como pasar de la 7 a la 8.
En la 7.4, todos los cambios de ruptura que se producirán en la 8 se marcan como obsoletos.
Esto te da tiempo y orientación para arreglarlos.
Sólo pasarás a la 8 cuando ya no queden depreciaciones.
Entonces, ¡cómo encontramos las obsoletas!
Este panel de registro de depreciaciones va a ser tu mejor amigo cuando actualices Symfony.
Parece que tenemos 3.
La primera es una deprecación de PHP.
El método de nuestra entidad necesita que un parámetro addDroid() Starship
se marque explícitamente como anulable.
Arreglemos eso primero.
Abre y desplázate hasta el método . src/Entity/Starship.php addDroid()
Ahh, incluso PhpStorm me avisa de esto.
La solución es sencilla, añade un ?
antes de : Vuelve al navegador, actualiza la página de inicio, y... DateTimeImmutable
todavía 3 deprecations...
No se ha borrado.
A veces, cuando se corrigen las depreciaciones, es
necesario borrar manualmente la caché de Symfony para que las recoja.
Esto se debe a que algunas deprecaciones se detectan en tiempo de compilación
cuando se está construyendo el contenedor.
Así que en tu terminal, ejecuta: Actualiza la página de nuevo... symfony console cache:clear
Vaya, ahora tenemos 4 desaprensiones.
Abre el panel.
Nuestra deprecación ha desaparecido, así que la hemos arreglado. addDroid()
A veces, cuando limpias la caché manualmente, se activan otras imprecisiones.
Vale, 3 de ellas son de Doctrine.
Tendremos un capítulo entero sobre la actualización de Doctrine un poco más adelante, así que las ignoraremos por ahora.
La cuarta es una opción de configuración obsoleta de zenstruck/foundry.
Antes de arreglarla manualmente, actualicemos primero nuestras recetas Symfony Flex.
A veces, simplemente actualizándolas se arreglan las obsoletas por ti.
Para actualizar las recetas, en tu terminal, ejecuta:
symfony composer recipe:update No ha funcionado.
Dice que tenemos cambios no comprometidos.
El comando de actualización de recetas debe ejecutarse desde cero, sin cambios pendientes.
Ejecuta: Para ver nuestros cambios. git status
composer.json, , y nuestro . composer.lock Starship.php
Tiene sentido, vamos a confirmarlos:
git commit -a -m "composer update" -a añade todos los archivos modificados
a la lista de cambios antes de confirmar y nos permite establecer un mensaje de confirmación. -m
Borrón y cuenta nueva, así que vuelve a ejecutar el comando de actualización de la receta: Ooo, tenemos un montón que actualizar.
Los revisaremos uno a uno.
Al pulsar enter utilizaremos el primero de la lista, . doctrine/deprecations
"No se ha modificado ningún archivo...". Ejecuta para ver qué pasa. git status
Sólo se ha modificado el archivo . symfony.lock
Este es el archivo de configuración interno que Symfony Flex utiliza para mantener un registro de tus recetas.
Podemos confirmar esto y seguir adelante: ¡Adelante! git commit -a -m "update recipes"
Ejecuta de nuevo el comando de actualización de recetas: es el siguiente... asset-mapper
Otra vez el archivo . symfony.lock
Cuando actualizo recetas, me gusta guardar todas las actualizaciones en un único commit.
Así que modificaremos los nuevos cambios con el commit anterior con: git commit -a
--amend Esto abre un editor de texto para actualizar opcionalmente el mensaje de confirmación.
Saldré para mantenerlo igual.
Ahora actualiza la receta de ... framework-bundle
Ooo, este tiene algunos cambios reales.
Lo bueno de este comando es que muestra el CHANGELOG del repositorio symfony/recipe,
así que puedes indagar fácilmente para entender por qué se ha hecho un cambio.
Ejecuta para ver los cambios. git status
Aparte del archivo , se modificó . symfony.lock public/index.php
¡Vamos a comprobarlo!
Abre y observa el cambio... public/index.php
Parece que se ha añadido la palabra clave . static
Creo que es una microoptimización útil, ¡la mantendremos!
Este es un buen momento para mencionar que nunca debes actualizar recetas a ciegas.
Comprueba siempre los cambios y, si no estás seguro de un cambio, sigue el registro de cambios
hasta el repositorio symfony/recipe para encontrar el razonamiento.
Modifica el commit y pasa a la siguiente actualización de recetas.
El también tiene algunos cambios. monolog-bundle
Parecen de configuración del paquete, así que abre para verlos. config/packages/monolog.yaml
Sólo se han eliminado algunos comentarios.
No es gran cosa...
modifica el commit.
A continuación, actualiza la receta y verás los cambios. stimulus-bundle
Abre . assets/stimulus_bootstrap.js
Sólo se han añadido algunas cosas.
Modifica el commit y pasa a actualizar la receta . twig-bundle
Nuestra plantilla base fue modificada, así que abre . templates/base.html.twig
Se han añadido algunas cosas de FrankenPHP.
De momento no utilizamos FrankenPHP, pero no está de
más dejarlo por si lo hacemos en el futuro
Modifica el commit y actualiza la última receta: . zenstruck/foundry
Se modificó el archivo de configuración, así que abre . config/packages/zenstruck_foundry.yaml
Sólo se ha actualizado un comentario, así que no pasa nada.
Modifica el commit y ¡habremos terminado!
Ejecuta de nuevo el comando de actualización de la receta para confirmar.
¡Qué bien! "Todos los paquetes parecen estar actualizados"
Antes de comprobar la aplicación, limpia de nuevo la caché...
Ahora actualiza la página de inicio.
2 desapariciones.
La del cargador automático de Doctrine sigue aquí, pero la ignoraremos hasta que actualicemos Doctrine.
La de Foundry también sigue aquí, así que la actualización de la receta no la ha arreglado.
Vamos a arreglarlo nosotros.
Dice que esta configuración de enable_auto_refresh_with_lazy_objects
se forzará a en la 3.0, así que pongámosla ahora en . true true
Copia la opción y abre . config/packages/zenstruck_foundry.yaml
En , pégala y ajústala a : Totalmente al margen, zenstruck_foundry true
pero si tienes curiosidad por saber qué es esta extraña sintaxis de y , se trata de un ancla y un alias de YAML. &dev *dev
El marca esta configuración como un ancla llamada , &dev dev
y luego el es un alias que hace referencia a esa ancla. *dev
Esto quiere decir: "para el entorno , utiliza la misma configuración que ". test dev
Es una forma genial de evitar la duplicación en tus archivos YAML.
Vale, vuelve al navegador y actualiza la página de inicio.
¡Ya no hay depreciaciones!
Pero... vamos a borrar la caché...
y actualicemos de nuevo...
ahora hay 3, pero son las de Doctrine que arreglaremos más tarde.
Vale, hemos actualizado con éxito nuestra aplicación a PHP 8.4.
A continuación, actualizaremos a Symfony 7.4, la última versión de Symfony 7.