Symfony 4: Los paquetes de la comunidad

Symfony Flex todavía no ha sido publicado, pero en la comunidad ya hay muchas ganas de probarlo. Hemos recibido un montón de comentarios via Twitter, Slack y correo electrónico, así que estamos encantados.

Confesamos que nos encanta poneros los dientes largos. Crear expectación sobre algo en lo que has trabajado durante los últimos meses es genial. Pero la realidad es un poco más compleja: Fabien todavía está trabajando en toda la infraestructura necesaria para hacer que Symfony Flex funcione.

La buena noticia es que casi todo está listo. La mala noticia es que después de los comentarios que hemos recibido, nos hemos dado cuenta de que algunas de las opciones que teníamos previstas para más adelante tendremos que incluirlas en la primera versión de Symfony Flex. Así conseguiremos que Flex sea realmente imprescindible para toda la comunidad Symfony.

La mayor preocupación de la gente es ese "repositorio selecto" que solamente contendrá las "recetas" de Symfony Flex que nosotros hayamos elegido. Antes de seguir, recuerda que el principal objetivo de Flex es automatizar parte de tu trabajo y hacer que sea más placentero.

En primer lugar, repetimos que no hace falta crear recetas de Symfony Flex para poder instalar un paquete. La forma que has utilizado hasta ahora para instalar bundles va a seguir funcionando: copiar/pegar algunos contenidos de un README, ejecutar algún comando, etc. Así que, en el peor de los casos, con Flex todo va a ser como mínimo igual que hasta ahora.

Debido a los motivos que se explicaron en el anterior artículo, el repositorio oficial va a ser restringido ("curated" en inglés). Cada día hablamos con un montón de programadores y empresas que usan Symfony y la mayoría nos piden que seleccionemos los mejores paquetes/bundles. La mayoría no tienen tiempo de analizar las decenas de alternativas que hay para cada cosa antes de tomar una decisión.

Relacionado con esto, las recetas de Symfony Flex tienen otra opción de configuración que no habíamos mencionado hasta ahora y que se llama aliases. En vez de utilizar el nombre oficial de un paquete (ejemplo: symfony/monolog-bundle) puedes usar un alias corto y fácil de recordar (ejemplo: logger). Y vamos a definir un montón de aliases útiles: admin, api, orm, mailer, etc. Cada uno de estos alias solo puede estar asociado a un paquete. Y ahí es donde nos toca a nosotros tomar decisiones.

Pero, ¿y si creamos otros repositorios de recetas además del oficial? Precisamente esa era una de las funcionalidades que teníamos en la lista de tareas para el futuro. Pero hemos decidido acelerar su desarrollo para disponer de ella cuanto antes. Y lo cierto es que nos encanta esta nueva opción.

Veamos en detalle cuáles son los dos repositorios de recetas que soportará Symfony Flex:

• El repositorio oficial será https://github.com/symfony/recipes y estará restringido. Cualquier propuesta para añadir nuevas recetas será revisada a conciencia. De hecho, el "core team" de Symfony tendrá que aprobar cada pull request (igual que hacemos para el código del repositorio symfony/symfony). Lo que buscamos es la máxima calidad posible y una experiencia de uso increíble.

• El repositorio de la comunidad será https://github.com/symfony/recipes-contrib y será autoregulado. La comunidad decidirá libremente si los pull requests se aceptan o no.

Además de cómo se aprueban las propuestas de recetas, las dos repositorios se diferenciarán en:

• Solo el repositorio principal puede definir "aliases" para los paquetes;
• Por defecto, Symfony Flex solo busca paquetes en el repositorio principal. Para buscar también en el repositorio público, añade "flex-allow-contrib": true en la sección extra del archivo composer.json del proyecto.

Los paquetes del repositorio público podrán pasarse con el tiempo al repositorio principal.

Para mantener un mínimo nivel de calidad, hemos creado una serie de validaciones automatizadas para las recetas. Cuando crees un pull request, el servidor de Symfony Flex realiza un montón validaciones para asegurar que la receta es correcta: desde cosas básicas como asegurar que el paquete asociado realmente existe en Packagist hasta validaciones más avanzadas como comprobar que dos paquetes no tienen el mismo "alias":

Además, el servidor de Symfony Flex crea un repositorio dedicado para cada pull request abierta de manera que puedas probar todos los cambios en tu propio ordenador fácilmente antes de hacer merge en la pull request:

Por ejemplo, si tu pull request es la número 42 del repositorio de la comunidad y está asociada a un paquete llamado foo/bar, puedes probar a instalar el nuevo paquete definiendo la siguiente variable de entorno FLEX_ENDPOINT:

FLEX_ENDPOINT=https://pr42.contrib.flex.symfony.com/ composer req foo/bar

Si la pull request va al repositorio principal, la variable de entorno incluso funciona al crear proyectos con Composer:

FLEX_ENDPOINT=https://pr42.flex.symfony.com/ composer create-project symfony/skeleton demo

Eso es todo por el momento. Esperamos que estos cambios de última hora hayan resuelto algunas de las dudas que teníais sobre el funcionamiento de Symfony Flex.

Este artículo es una traducción del artículo Symfony 4: Contributing Recipes publicado por Fabien Potencier.

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