Symfony 4: Estrutura de Diretório

O Symfony 3 veio com uma estrutura de diretório ligeiramente diferente do Symfony 2. O Symfony 4 também virá com uma estrutura de diretório retrabalhada. Principalmente ajustes incrementais para suportar novos recursos e melhores práticas.

A estrutura de diretório do Symfony 3 introduziu uma estrutura mais parecida com padrão do Unix, com menos subdiretórios. O Symfony 4 continua nesse sentido.

A utilização de nomes de diretório bem conhecidos ajuda. O uso de bin/, src/, ou var/ foi um grande passo à frente. O Symfony 4 adiciona etc/ no lugar de app/. Isso já havia sido proposto para o Symfony 3, mas rejeitado por razões que não se aplicam mais.

Testes sob tests/

Os testes foram movidos para um diretório de nível superior tests/. Foi proposto antes, porém somente faz sentido agora que temos aplicações sem bundles. Também permite declarar um namespace específico de teste para autoloading:

{
    "autoload": { "psr-4": { "App\\": "src/" } },
    "autoload-dev": { "psr-4": { "App\\Tests\\": "tests/" } }
}

Templates sob templates/

Os templates tornam-se cidadãos de primeira classe através de um novo diretório de nível superior templates/. Faria mais sentido usar tpl como nos outros nomes de diretórios curtos de 3 letras?

Por que não views? views foi o nome original escolhido há muito tempo atrás porque era mais curto do que templates. Foi um erro pois view é um conceito por si só. Corrigido, finalmente.

Ter templates no nível de raiz também facilita o trabalho com web designers. E esse diretório só é criado quando você instala o Twig.

Mover os templates permite reservar o src/ para classes PHP apenas, sem mais recursos. Outra conseqüência de não ter mais bundles.

Configuração sob etc/

O novo diretório etc/ é o equivalente ao diretório atual app/config/. Mas com um layout muito diferente. Os arquivos parameters.yml e parameters.yml.distdesapareceram.

O ponto de entrada principal para o container é um container.yaml vazio que você pode usar para definir os seus próprios serviços e parâmetros. A configuração dos bundles que você instala via Composer é armazenada em arquivos individuais. Um arquivo por bundle e por ambiente. O mesmo acontece com a configuração de roteamento. Esse é um requisito para auto-configuração, mas também permite uma melhor organização de arquivos.

Os arquivos de configuração podem ser escritos em PHP, XML ou YAML, como antes. A única diferença é o uso da extensão padrão .yaml em vez da atual .yml.

Uma mudança importante é a introdução de um arquivo bundles.php onde os bundles instalados são referenciados.

Um arquivo por bundle e bundles.php são os dois conceitos principais que permitem que o Symfony gerencie automaticamente os seus bundles e as suas configurações.

Código fonte em src/

A classe Kernel foi movida para src/, onde ela pertence. O conteúdo é muito diferente do Symfony 2. Primeiro, ele usa a trait MicroKernelTrait. Então, ele implementa a lógica para carregar os bundles a partir do arquivo bundles.php e para ler os vários arquivos de configuração do bundle. A lógica funciona a partir do Symfony 3.3. Por exemplo, o código que carrega os arquivos de configuração do container é o seguinte:

protected function configureContainer(ContainerBuilder $container, LoaderInterface $loader) {
    $confDir = dirname(__DIR__).'/etc'; $loader->import($confDir.'/packages/*'.self::CONFIG_EXTS, 'glob');
    if (is_dir($confDir.'/packages/'.$this->getEnvironment())) {
        $loader->import($confDir.'/packages/'.$this->getEnvironment().'/**/*'.self::CONFIG_EXTS, 'glob');
    }
    $loader->import($confDir.'/container'.self::CONFIG_EXTS, 'glob');
}

Arquivos temporários sob var/

var/ é muito semelhante ao Symfony 3, com alguns pequenos ajustes para melhores práticas.

var/cache/ agora só deve ser usado para armazenar conteúdos em cache de longo prazo, como arquivos de container compilados, traduções compiladas, ou proxies do Doctrine. Nenhum arquivo temporário. Basicamente, qualquer coisa armazenada em var/cache deve ter uma classe de warmup capaz de gerar os arquivos de cache. Arquivos que nunca devem ser atualizados após a implantação para permitir sistemas de arquivos somente leitura.

E quanto aos arquivos temporários? Use outro diretório como var/tmp/. Ou apenas o diretório Unix padrão /tmp.

Se você seguir essa melhor prática, podemos garantir um diretório /var/cache somente leitura em algum momento. Ter diretórios somente leitura é um requisito de algumas plataformas de hospedagem como Heroku ou SensioCloud e ajuda a escalar uma aplicação. Provavelmente não para o Symfony 4.0.

Arquivos da Web sob web/

Já foi mencionado um único front controller web sob a web/. Quase todos os outros arquivos foram removidos. Sem config.php. Sem .htaccess. Não há favicon.ico ou apple-touch-icon.png. Nem mesmo robots.txt. Nem todos os projetos precisam desses arquivos. Se você quiser esqueletos para esses arquivos, você terá essa opção também, claro.

Tudo é opcional

Uma diferença com o Symfony 3 é que todos os diretórios de primeiro nível são opcionais. Não usa templates em sua API? Não é necessário criar um diretório templates/. Os diretórios são criados sob demanda, em qualquer caso.

Ao usar o Composer para adicionar um novo bundle, o Symfony 4 utiliza essa nova estrutura de diretório para registrar automaticamente o bundle em bundles.php, copiar alguma configuração sensível sob etc/, e muito mais. Você pergunta: O que mais? Grande tópico para a próxima postagem.

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