Explorando os arquivos de Stubs do Framework Laravel

Olá, meu nome é Stefano Ducci e eu sou desenvolvedor Sênior na Convenia, hoje vou falar um pouco sobre os arquivos Stubs do framework Laravel que utilizamos aqui para o desenvolvimento do nosso software.

O que me levou a escrever esse artigo foi a pouca informação a respeito disso disponível hoje, incluindo a própria documentação do Laravel que carece de exemplos de customização de arquivos.

O que são?

Os arquivos Stubs nada mais são do ‘arquivos de configuração’ para criação automatizada de classes através dos comandos artisan make do próprio framework. Utilizando um projeto Laravel na versão 8, segue abaixo um exemplo de um arquivo gerado automaticamente pelo comando php artisan make:model com o Stub paradão do framework.

Nele podemos ver algumas configurações padrões da versão 8 do framework como o uso da Trait HasFactory, que veio junto com essa release para facilitar no desenvolvimento de testes automatizados. Além disso, é possível ver a extensão e a importação da classe Model nativa do próprio Laravel. Mas então, como customizamos esses padrões para se adequarem aos nossos projetos?

Customização

Para que seja possível customizar esses arquivos Stubs, é necessário rodar o comando php artisan stub:publish que irá importar para o seu projeto todos os arquivos Stubs que o Laravel possui por padrão para dentro de uma pasta chamada stubs em sua raiz, é importante que a localização desse diretório não seja alterada pois na hora de executar os comandos make, ele irá procurar pelos arquivos de customização nesse caminho e caso não os encontre, usará seu arquivo padrão, ou seja, uma vez importados, não é necessário que você mantenha todos os arquivos stubs no seu projeto, somente aqueles que possuem alguma customização. Abaixo segue um exemplo de alguns arquivos importados pelo comando mencionado acima:

É possível notar que alguns arquivos como os Controller, possuem mais de um arquivo passivo de customização, isso se dá pois dependendo de como você executar o comando make, um determinado Stub será usado para criação do novo arquivo. Por exemplo, o comando: “php artisan make:controller TestController --model Test --resource”, o stub que será usado será o controller.model.stub, já quando usamos o comando php artisan make:controller TestController sem nenhuma opção, o arquivo que será utilizado será o controller.stub.
Mas e então, como utilizar esses arquivos de forma efetiva?

Utilização

Aqui na Convenia, em um dos nossos projetos, nós optamos por usar um banco de dados não relacional e para esse desafio escolhemos utilizar o banco MongoDB, que nos permite certas liberdades que esse projeto necessita, para que o Laravel conseguisse conversar bem com essa arquitetura, nós adicionamos ao projeto a biblioteca jenssegers/laravel-mongodb que traz uma abordagem bem simples para interagir com os dados do banco, além de trazer uma linguagem muito próxima da classe Model do próprio Laravel.
E junto com a descoberta dos Stubs, veio a possibilidade de padronizar a criação de nossas Models alterando a classe mãe de todas elas já no momento de criação, segue abaixo o arquivo Stub customizado:

E esse foi o resultado do arquivo gerado com o mesmo comando php artisan make:model Test:

Outras customizações que podemos trazer para esse arquivo de Stub são por exemplo, o uso de chave primária do tipo texto e o autoincrement como falso, uma vez que adotamos o uso de chaves primárias no modelo UUID em vez do uso de id’s inteiros incrementais, deixando nosso arquivo assim:

Ou até mesmo adicionando ao nosso template as variáveis usadas pela biblioteca do Jenssegers para conexão com o banco de dados:

Conclusão

Esses foram somente alguns exemplos de como os arquivos de Stub do Laravel podem facilitar o seu desenvolvimento do dia a dia, diminuindo o número de vezes que você reescreve código em classes com a mesma estrutura e trazendo um pouco de padronização entre as classes do seu sistema.
Aqui na Convenia nós percebemos que esse tipo de abordagem traz muito mais facilidade para acoplar um novo desenvolvedor a um projeto, fazendo com que os Stubs acabem se tornando um tipo de documentação de como as coisas são feitas naquela projeto, principalmente na estrutura distribuída de microsserviços que temos hoje onde cada projeto pode ter suas próprias características.