Symfony 4: Automatize o seu Fluxo de Trabalho

O recurso mais “inovador” do Symfony 4 é o modo como ele lida com o gerenciamento dia-a-dia da aplicação. Não há mais o tedioso copiar/colar de arquivos README. Não há mais código boilerplate. Automação ao máximo. Em uma lista com curadoria de pacotes do Composer.

Symfony Flex

O Symfony 4 é alimentado pelo Symfony Flex, um plugin do Composer enganosamente simples, mas poderoso. O esqueleto padrão do Symfony apenas lista duas dependências principais: symfony/flex e symfony/framework-bundle. Todo o restante é opcional.

Como você pode imaginar, a maioria dos projetos precisa de mais que o FrameworkBundle. E instalar e configurar todos os pacotes e bundles manualmente é algo propenso a erros, tedioso e simplesmente chato. Mesmo para as poucas dependências que a Edição Standard do Symfony possui.

É aí que o Symfony Flex brilha.

Quando você instala um pacote do Composer, o Flex engancha no processo de instalação para automatizar sua integração em seu projeto através de receitas pré-definidas e voltadas para a comunidade. Funciona para quaisquer pacotes Composer, não apenas os bundles Symfony. Se uma receita não existe, você ainda pode configurá-la da maneira antiga, como é feito atualmente.

Pegue o sensiolabs/security-checker como exemplo. Ele funciona para qualquer projeto PHP. Mas quando instalado em um projeto usando o Symfony Flex, ele sabe como executar o verificador sempre que você executar composer install.

A automação é implementada em uma receita que possui um manifesto JSON que descreve como integrar o pacote em uma aplicação Symfony. Aqui está a do sensiolabs/security-checker:

{
    "copy-from-recipe": {
        "etc/": "%ETC_DIR%/"
    },
    "composer-scripts": {
        "vendor/bin/security-checker security:check": "php-script"
    }
}

O Flex atualmente implementa 9 “configuradores” que ajudam a automatizar a integração de qualquer pacote PHP em uma aplicação Symfony: copy-from-recipe, copy-from-package, bundles, env, container, makefile, composer-scripts, gitignore, e post-install-output.

Bundles

O configurador de bundles habilita bundles em seu projeto adicionando-os ao arquivo bundles.php (e os remove quando você desinstala a dependência):

{
    "bundles": {
        "Symfony\\Bundle\\DebugBundle\\DebugBundle": ["dev", "test"],
         "Symfony\\Bundle\\MonologBundle\\MonologBundle": ["all"]
    }
}

Configuração

A configuração pode ser adicionada através dos configuradores copy-from-recipe and copy-from-package: o primeiro copia arquivos da receita enquanto o segundo copia os arquivos do próprio pacote Composer.

{
    "copy-from-package": {
        "bin/check.php": "%BIN_DIR%/check.php"
    }, 
    "copy-from-recipe": {
        "etc/": "%ETC_DIR%/",
        "src/": "%SRC_DIR%/"
    }
}

Variáveis de Ambiente

O configurador env sabe como adicionar variáveis ​​de ambiente aos arquivos .env e .env.dist do projeto (e os remove ao desinstalar a dependência):

{
    "env": {
        "APP_ENV": "dev",
        "APP_DEBUG": "1"
    }
}

Tarefas Makefile

O configurador makefile adiciona novas tarefas ao Makefile do projeto (e as remove ao desinstalar a dependência). Ao contrário de outros configuradores, não há uma entrada no manifest.json. Basta definir as tarefas em um arquivo Makefile:

cache-clear:
    @test -f bin/console && bin/console cache:clear --no-warmup || rm -rf var/cache/*
.PHONY: cache-clear
cache-warmup: cache-clear
    @test -f bin/console && bin/console cache:warmup || echo "cannot warmup the cache (needs symfony/console)"
.PHONY: cache-warmup

Scripts do Composer

O arquivo composer.json definido em symfony/skeleton contém o seguinte snippet:

{
    "scripts": {
        "auto-scripts": [ ],
        "post-install-cmd": [ "@auto-scripts" ],
        "post-update-cmd": [ "@auto-scripts" ]
    }
}

O configurador composer-scripts gerencia a seção especial @auto-scripts adicionando comandos e scripts definidos em receitas. Esses são executados automaticamente em composer install e composer update:

{
    "composer-scripts": {
        "assets:install --symlink --relative %WEB_DIR%": "symfony-cmd"
    }
}

.gitignore

O configurador .gitignore adiciona padrões ao arquivo .gitignore. E, como para os outros configuradores, sabe como limpar quando você remove um pacote:

{
    "gitignore": [
        "/phpunit.xml"
    ]
}

post-install-output

Se você quiser exibir algumas ações de próximo passo quando um pacote é instalado, liste-as através do configurador post-install-output. Como no Makefile, a saída deve ser definida em um post-install.txt:

Execute <fg=blue>make serve</> to run your application.

Exemplo completo

O manifesto mais “complexo” é atualmente o do symfony/framework-bundle que é o seguinte:

{
    "bundles": {
        "Symfony\\Bundle\\FrameworkBundle\\FrameworkBundle": ["all"]
    },
    "copy-from-recipe": {
        "etc/": "%ETC_DIR%/",
        "src/": "%SRC_DIR%/",
        "web/": "%WEB_DIR%/"
    },
    "composer-scripts": {
        "make cache-warmup": "script",
        "assets:install --symlink --relative %WEB_DIR%": "symfony-cmd"
    },
    "env": {
        "APP_ENV": "dev",
        "APP_DEBUG": "1",
        "APP_SECRET": "%generate(secret)%"
    },
    "gitignore": [
        ".env",
        "/var/",
        "/vendor/",
        "/web/bundles/"
    ]
}

Isso é tudo. Ainda temos que encontrar um caso não coberto por este pequeno conjunto de configuradores. Note que poderá ser removido o container, uma vez que não é usado mais no conjunto atual de receitas escritas até agora.

Um repositório de opinião

O repositório de receitas do Symfony Flex será opinativo. O desenvolvedor é livre para usar qualquer combinação de pacotes, mas para poder fornecer uma boa configuração sensata, precisamos fazer escolhas. Não poderemos suportar todos os pacotes, apenas um conjunto com curadoria deles. O que provavelmente também é uma algo bom.

O Symfony não faz escolhas para você. E isso faz sentido. Você sabe o que precisa para o seu projeto. Mas com mais de 3000 pacotes para escolher, selecionar o pacote correto do ecossistema está longe de ser fácil para iniciantes. Quer um gerador admin? Atualmente, você precisa escolher entre 26 diferentes. E vários são bastante populares. Qual devo usar?

Compare isso com o symfony1, onde o gerador admin foi incorporado. Esse é apenas um exemplo. Dê uma olhada no número de bundles de Blog ou de API. A ótima notícia é que a comunidade Symfony está trabalhando duro.

Ao longo dos anos, o Symfony tornou-se um framework de muito baixo nível, sem baterias inclusas. Agora que o Symfony nos oferece uma plataforma muito poderosa para trabalhar, acho que podemos trabalhar novamente em ser mais opinativo.

Devemos dar mais exposição a bons bundles. Para fazer isso, primeiro precisamos definir o que significa “bom”. Podemos imaginar algumas regras simples como a licença, ou o número de bugs abertos vs atividade no repositório Git, a quantidade de documentação, o número de contribuidores, se é compatível com um grande conjunto de versões do Symfony e assim por diante.

E, claro, qualquer bundle ainda pode ser instalado da maneira antiga, sem auto-configuração.

O Servidor Symfony Flex

Além de ser um plugin do Composer, o Symfony Flex também se comunica com um servidor HTTP para obter informações atualizadas sobre receitas de pacotes, alias e muito mais.

Experimente curl https://flex.symfony.com/recipes/sensiolabs/security-checker/4.0 | json_pp.

Ansioso para experimentar o Symfony Flex? Tudo já encontra-se no Github!

Tradução do artigo original publicado por Fabien Potencier “Symfony 4: Automate your Workflow”