Symfony 4: Contribuindo com Receitas

As pessoas estão preocupadas com o repositório de receitas opinativo. Tenha em mente que um dos principais objetivos do Symfony Flex é facilitar o seu dia-a-dia automatizando seu fluxo de trabalho.

Primeiro, reiteraramos que um pacote não precisa ter uma receita para ser instalado. A boa forma antiga de registrar bundles manualmente e copiar/colar alguma configuração padrão ainda funcionará bem … que é o que todos têm feito há anos. Em outras palavras, tudo será, ao menos, tão fácil de instalar quanto agora.

Então, por várias razões explicadas no post anterior, o repositório oficial será opinativo. Muitos desenvolvedores e empresas que usam o Symfony, querem que “nós” realizemos as escolhas por eles. Eles não querem testar dezenas de bundles para fazer uma escolha informada.

Finalmente, revelamos mais uma opção de configuração de receita que ainda não foi mencionada: aliases. Em vez de usar o nome regular do pacote Composer, uma receita pode listar nomes mais curtos alternativos. Por exemplo, use composer req cli ao invés de composer req symfony/console. Você pode imaginar pacotes dispostos a reservar os alias admin, api, ou orm. E, é claro, cada alias só pode ser vinculado a um pacote Composer.

As escolhas são boas.

Mas e quanto a ter outro repositório de receitas ao lado do principal? Bem, esse recurso estava na lista de tarefas para uma versão futura. Mas resolvemos incluir agora na primeira versão.

Vamos mergulhar nos respositórios de receita do Symfony Flex. Em vez de ter apenas um repositório, o Symfony Flex suporta dois.

Veja como funciona:

• O repositório oficial “principal”, hospedado em https://github.com/symfony/recipes, será opinativo. As submissões serão revisadas cuidadosamente. Elas precisarão de aprovação da equipe principal do Symfony (como ocorre com os pull requests no repositório principal symfony/symfony). Queremos a máxima qualidade e a melhor experiência para o desenvolvedor.
• O repositório “contrib”, hospedado em https://github.com/symfony/recipes-contrib não será opinativo. Com curadoria da comunidade em geral, a maioria das submissões serão aceitas.

Além das regras para aceitar submissões, os repositórios “principal” e “contrib” funcionam exatamente da mesma maneira, exceto pelas seguintes diferenças:

• Somente o repositório “principal” pode definir alias (supomos que isso faz sentido);
• Por padrão, o Symfony Flex procura apenas receitas no repositório “principal”. Usar o repositório “contrib” é opt-in. Habilite-o executando composer config extra.symfony.allow-contrib true.

E os pacotes podem ser promovidos do repositório “contrib” para o “principal” também.

Para manter um alto nível de qualidade, foi desenvolvido um conjunto de regras de validação para receitas. Quando você envia um pull request em ambos os repositórios, o servidor Symfony Flex executa uma série de verificações para garantir que suas alterações são válidas. Verificações básicas, como a validação da existência do pacote no Packagist. E mais interessantes, como verificar se dois pacotes não definiram o mesmo alias.

Mas, mais interessante, um servidor Flex Server de staging é construído para cada pull request. Isso permite a qualquer um testar as mudanças antes de serem incorporadas na branch master/production de um repositório.

Por exemplo, se você enviar um pull request (número 42) no repositório “contrib” que adiciona uma receita para o pacote “foo/bar”, instale seu novo pacote definindo a variável de ambiente SYMFONY_ENDPOINT:

SYMFONY_ENDPOINT=https://symfony.sh/r/contrib/42 composer req foo/bar

Se as alterações forem enviadas para pacotes “core” (como no symfony/framework-bundle), o uso da variável de ambiente também funciona com composer create-project:

SYMFONY_ENDPOINT=https://symfony.sh/r/main/42 composer create-project symfony/skeleton demo

Tradução do artigo original publicado por Fabien Potencier “Symfony 4: Contributing Recipes”