Se publica Symfony 4.0

Symfony 4, la mejor versión Symfony de la historia, acaba de ser publicada. Symfony 4 es el resultado de dos años de trabajo y miles de commits y pull requests por parte de cientos de programadores/as de toda la comunidad.

Todo es diferente, todo es mejor

El lanzamiento de Symfony 3 supuso una mejora significativa sobre Symfony 2, pero incomparable respecto al cambio disruptivo que supone Symfony 4. Hemos repensado las ideas y fundamentos básicos del framework, mejorando o eliminando todas ellas para hacer un framework más moderno y adaptado a las nuevas necesidades del mercado.

Todos los conceptos que conoces sobre Symfony (controladores, servicios, eventos, etc.) se mantienen, pero la implementación de muchos de ellos cambia radicalmente. Y cambia a mejor, ya que hemos eliminado muchas "ideas Symfony" para reemplazarlas por "ideas estándar en la industria del software".

El resultado es una versión de Symfony en la que tienes que aprender menos cosas, configurar menos cosas, tocar menos cosas, programar menos cosas y en definitiva, dedicar menos tiempo a Symfony y más tiempo a tus proyectos.

Principales novedades

Durante las últimas semanas hemos publicado varios artículos explicando en detalle las novedades de Symfony 4.0. Estas son las tres principales:

1) Estructura de directorios simple

Al crear un nuevo proyecto Symfony, estos son los directorios que verás:

bin/
    console
config/
public/
    index.php
src/
    Kernel.php
tests/
var/
    cache/
    log/
vendor/

Y cuando la aplicación crezca y añadas assets o plantillas o archivos de traducción, esta será la estructura de directorios:

assets/
bin/
    console
config/
public/
    index.php
src/
    Kernel.php
templates/
tests/
translations/
var/
    cache/
    log/
vendor/

La estructura es plana (todo son directorios de primer nivel, sin jerarquías) y auto-explicativa: la configuración está en config/, las plantillas en templates/, las traducciones en translations/, etc. Gracias a este cambio, ahora todo es obvio y no requiere de ninguna explicación.

2) Aplicaciones mucho más pequeñas

Al contrario que en Symfony 3, las aplicaciones Symfony 4 no se basan en la edición estándar de Symfony. Cuando creas una aplicación, no se instalan todos los componentes y bundles de Symfony. Solamente se instalan las componentes mínimos para hacer una aplicación (HttpKernel, HttpFoundation, Routing, etc.)

La consecuencia es que las aplicaciones son mucho más pequeñas. De hecho, una aplicación Symfony 4 nueva contiene un 70% menos de código y de archivos que una aplicación nueva de Symfony 3.

Además, las aplicaciones utilizan un micro-kernel y ya no están optimizadas exclusivamente para hacer aplicaciones web tradicionales. Symfony 4 es adecuado para hacer microservicios, aplicaciones web monolíticas, aplicaciones de consola, backends para aplicaciones JavaScript, etc.

3) Automatización

Si las aplicaciones nuevas no instalan casi ningún componente o bundle, ¿cómo consigo un mailer o un logger en mi aplicación? En el pasado tenías que buscar algún bundle en GitHub or Packagist.org, leer sus instrucciones de instalación, activar el bundle en el kernel de la aplicación, etc.

En Symfony 4, gracias a una herramienta llamada Symfony Flex, podrás instalar bundles, componentes y librerías de terceros más fácil que nunca. ¿Quieres un mailer? Ejecuta composer require mailer. ¡Ya está! ¿Quieres un logger? composer require logger (o composer require logging o composer require logs o composer require monolog, etc. ¡todo funciona!). ¿Echas de menos el profiler? composer require profiler ¿Quieres usar Doctrine? composer require doctrine. Fácil, rápido y, otra vez, tan obvio que no requiere muchas explicaciones.

La automatización no acaba ahí. Gracias al autowiring de servicios, puedes utilizar los servicios en tu aplicación sin tener que configurarlos. Symfony crea automáticamente los servicios por ti y también añade las etiquetas para los servicios que lo requieran. Pero no te preocupes, esto no es magia, es solo automatización. Si un servicio no puede configurarse de forma inequívoca, Symfony te avisará con un mensaje de error muy claro.

Por ejemplo, cuando creas una extensión de Twig en Symfony 3.2, la tienes que definir como servicio antes de utilizarla:

services:
    app.twig_extension:
        class: AppBundle\Twig\AppExtension
        public: false
        tags:
            - { name: twig.extension }

En Symfony 4, como tu clase AppExtension extiende de \Twig_Extension, que a su vez implementa Twig\Extension\ExtensionInterface, Symfony ya sabe que estás creando una extensión de Twig. Así que crea un servicio automáticamente cuyo ID es el namespace de tu clase y además, como es una extensión de Twig, le aplica la etiqueta twig.extension. Y lo mismo sucede con todas las demás clases del directorio src/. Se convierten en servicios si hace falta y se aplican las etiquetas correspondientes. Pero no es magia, es solo automatización.

¿Cómo crear una aplicación nueva basada en Symfony 4?

Ya no se recomienda utilizar el instalador de Symfony, así que simplemente ejecuta lo siguiente:

$ composer create-project symfony/skeleton mi-proyecto

¿Cómo actualizar una aplicación existente a Symfony 4?

Además de Symfony 4.0, hoy también se ha publicado Symfony 3.4, que es la clave para que puedas actualizar tus aplicaciones existentes a Symfony 4. La idea es que Symfony 3.4 y 4.0 tienen exactamente las mismas funcionalidades. Su única diferencia es que Symfony 3.4 tiene todavía todas las funcionalidades declaradas obsoletas en la rama 3.x (es decir, todo lo obsoleto de 3.0, 3.1, 3.2 y 3.3). Además, Symfony 3.4 es una versión LTS de largo soporte (errores corregidos hasta noviembre de 2020 y errores de seguridad hasta noviembre de 2021).

El plan para actualizar a Symfony 4 sería el siguiente:

1. En composer.json cambia las versiones de Symfony de 3.x a ^3.4.
2. Ejecuta composer update para actualizar todo.
3. Si no lo tienes, añade PHPUnit Bridge como dependencia en tu aplicación: composer require symfony/phpunit-bridge (esto es muy importante porque este componente es el que te muestra todas las funcionalidades obsoletas que usas en tu aplicación)
4. Ejecuta tus tests con este comando: ./vendor/bin/simple-phpunit (ese comando lo crea PHPUnit Bridge). Al acabar los tests, verás la lista de funcionalidades obsoletas que usa tu aplicación.
5. Elimina todos esos avisos y ya estarás listo/a para actualizar a Symfony 4.0. No puedes ejecutar Symfony 4.0 si tienes cualquiera de esos avisos, ya que en Symfony 3.4 son solo avisos, pero en 4.0 generan excepciones.
6. Para actualizar a 4.0, tendrías que utilizar ^4.0 como versión en composer.json y ejecutar composer update de nuevo. Todo funcionará porque Symfony 3.4 y 4.0 son idénticas.

Si prefieres eliminar todas las funcionalidades obsoletas a mano, puedes leer la Symfony 3.x to 4.0 Upgrade Guide donde se muestran todos los cambios y algunos ejemplos prácticos.

Cómo actualizar a la nueva estructura de directorios

Actualizar a Symfony 3.4 y 4.0 es más o menos fácil dependiendo de tu aplicación, pero actualizar a la nueva estructura de directorios te costará más. No es un cambio difícil, pero si tedioso, así que esta es la recomendación para automatizar el cambio:

1. Instala Symfony Flex en tu proyecto: composer require symfony/flex
2. Si en tu composer.json tienes symfony/symfony como dependencia, eso significa que dependes de la edición estándar de Symfony. Así que tienes que eliminarla (composer remove symfony/symfony) e instalar los componentes individuales que vayas a utilizar. Si no estás seguro, ejecuta esto para instalar casi todo (y luego ya eliminarás lo que no utilices): composer require annotations assets doctrine twig profiler logger mailer form fixtures security translation validator. Este comando creará todos los archivos de configuración en el directorio config/, que es la parte más tediosa del proceso.
3. Si en tu composer.json ya usabas los componentes individuales en vez de symfony/symfony ejecuta rm -fr vendor/* y composer install para generar los archivos de configuración de config/.
4. En config/ ahora tienes todos los archivos de configuración por defecto, así que tienes que cambiarlos según los contenidos de tus archivos originales en app/config/. Cuando acabes, ya puedes eliminar el directorio app/config/
5. El archivo más importante es config/services.yaml donde se configuran los servicios. Recuerda que Symfony 4 no hace falta configurar nada para la mayoría de servicios, así que no hace falta que copies el antiguo app/config/services.yml.
6. El resto de cambios son sencillos:
   • Mueve app/Resources/views/ a templates/
   • Mueve app/Resources/translations/ a translations/
   • Mueve src/AppBundle/* a src/ (usa PhpStorm para cambiar todos los namespaces automáticamente). Si tienes varios bundles, tienes que fusionar todos los archivos. Ejemplo: si antes tenías src/UserBundle/Controller/DefaultController.php y src/ProductBundle/Controller/DefaultController.php fusiónalos en src/Controller/UserController.php y src/Controller/ProductController.php.
   • Mueve los assets públicos como imágenes de src/AppBundle/Resources/public/ a public/images/, etc.
   • Mueve la fuente de los assets (e.g. archivos SCSS con los que generas los CSS) a assets/ y usa Webpack Encore.
   • Actualiza el autoload y autoload-dev en composer.json para utilizar App\ y App\Tests como namespaces. Aquí tienes un ejemplo.
   • Crea el controlador frontal public/index.php copiando este código y haz cualquier cambio que creas necesario según tus archivos actuales web/app.php y web/app_dev.php.
   • Actualiza el script bin/console copiando este código y cambiando lo que creas necesario según tu script console actual.

Cambiar la estructura de directorios es un poco tedioso, pero solo hay que hacerlo una vez en la vida del proyecto y como puedes ver, los cambios son todos a mejor. Todo es más sencillo, la estructura de directorios es más simple y sobre todo, tu aplicación está mucho menos acoplada a Symfony.

• © 2024 - symfony.es
• Contacto
• Privacidad
• Condiciones
• v7