Melhor código WordPress: o arquivo de bloqueio do compositor
Antes de encerrar nossa discussão sobre o Composer, temos uma coisa importante para discutir: o diretório do fornecedor (e, por extensão, o arquivo de bloqueio do Composer).
Especificamente, precisamos falar sobre por que não precisamos confirmar o diretório do fornecedor no repositório, mas como nossos contribuidores podem ter certeza de que têm a versão mais recente do software necessário para trabalhar com nossa base de código.
Usar ferramentas de qualidade de código para escrever melhor código WordPress é importante, sim, mas entender como gerenciar adequadamente as dependências e nosso repositório também é importante. Portanto, antes de examinar esses utilitários, vamos revisar o arquivo de bloqueio, o papel que ele desempenha e por que não precisamos confirmar o diretório do fornecedor em nosso repositório.
Melhor código WordPress com o arquivo de bloqueio do compositor
Para aqueles que trabalham com WordPress – e talvez em outros frameworks e fundações baseados em PHP (eu realmente não sei, já que costumo não trabalhar com eles) – há uma dependência do Composer, o que é uma coisa boa.
Isso também pode levar a querer comprometer todo o controle de origem do diretório do fornecedor, o que não é uma coisa boa.
Conforme mencionado no post anterior :
E eu não recomendo verificar o diretório do fornecedor em seu repositório. Isso pode se tornar um diretório enorme mais tarde, e pode minar todo o propósito do Composer.
Então, como podemos ter certeza de que não estamos submetendo arquivos desnecessariamente (e, portanto, inflando o tamanho do nosso repositório) para o repositório ao mesmo tempo, garantindo que nossos contribuidores estejam usando a mesma versão do software que nós?
O desejo de comprometer o diretório de fornecedores
Para aqueles que executaram o Composer e estão familiarizados com pelo menos ver o diretório do fornecedor, provavelmente estão acostumados a ver vários diretórios de dependências que estão instalados.
E eles são úteis; caso contrário, você não os teria incluído, certo?
Mas aqui está a coisa sobre o diretório do fornecedor : mesmo que você tenha apenas algumas dependências instaladas com seu projeto, o próprio tamanho do arquivo pode ser grande. E isso pode ser ainda maior quando você tem muitas dependências.
Independentemente disso, comprometer isso com o controle de origem parece fazer sentido, certo? Queremos garantir que todos tenham a mesma versão do software que estamos usando e queremos garantir que eles não precisem lidar com o Composer.
Há outra maneira, no entanto. E mantém nosso repositório pequeno ao mesmo tempo em que garante que as versões de nossas dependências sejam mantidas em sincronia com aqueles que clonam o repositório, fazem commit no repositório ou para qualquer utilitário de integração contínua que use o repositório.
Entendendo o arquivo de bloqueio
Antes de falar sobre o diretório do fornecedor, quero abordar outro aspecto importante do Composer: o arquivo de bloqueio. Ou seja, se você executar o comando install ou update em seu terminal, verá um arquivo de bloqueio gerado junto com o diretório do fornecedor.
O que é este arquivo?
O post anterior mostrou um arquivo de configuração de exemplo. Uma das coisas que esse arquivo também nos permite fazer é definir bibliotecas de terceiros, ou dependências, que podemos usar em nossos projetos.
Já falei sobre isso em outros posts (e podemos ver isso um pouco mais adiante nesta série). Mas é aqui que o arquivo de bloqueio entra em jogo.
Resumindo, o arquivo de bloqueio sempre contém informações sobre a versão – a versão exata – das dependências que estão sendo usadas com o projeto na última vez que a instalação ou atualização foi executada.
Quando o Composer termina de instalar, ele grava todos os pacotes e as versões exatas deles que baixou para o arquivo composer.lock, bloqueando o projeto para essas versões específicas.
Você deve enviar o arquivo composer.lock para o repositório do seu projeto para que todas as pessoas que trabalham no projeto sejam bloqueadas para as mesmas versões de dependências (mais abaixo).
O objetivo é garantir que todos estejam executando a mesma versão das dependências do projeto – nem versões mais antigas, nem versões mais recentes – mas a mesma versão.
Portanto, quando você executar o composer install quando um arquivo de bloqueio for incluído no repositório, usará a versão do software conforme definido no arquivo de bloqueio.
E isso garante que todos estejam executando a mesma versão de cada dependência e, portanto, pode evitar a necessidade de confirmar o diretório do fornecedor para o controle do código-fonte.
Escrevendo código de alta qualidade
Então, para onde vamos a partir daqui?
Agora que entendemos como usar o Composer e como usar o arquivo de bloqueio, podemos começar a falar sobre dependências reais que ajudam a melhorar a qualidade do nosso código.
E quando falamos em escrever código de maior qualidade, existem utilitários feitos exatamente para isso. Então, nos próximos posts, vamos ver alguns deles.