Composer: um jeito simples de entender
Desenvolvimento, Magento 2, Para Magenteiros
Atualizado em 24 de fevereiro de 2022
Composer é o gerenciador de pacotes e dependências mais utilizado no mundo PHP.
Ele é um pouco mais novo que o nosso Magento. Seu primeiro release aconteceu em 2012.
Neste rápido artigo, lhe ajudarei a entender o básico sobre esta ferramenta e para que servem os arquivos composer.json e composer.lock. Eles estão presentes na pasta raiz de quase todo projeto que o utiliza.
Navegação rápida
Porque usar o composer
Apesar de ser mais lento que muitos gerenciadores de pacotes de outras linguagens, o composer abre a porta para sermos muitos mais ágeis no desenvolvimento e entrega de projetos. Note que a lentidão a qual me refiro é apenas na sua execução em busca de dependências e atualizações, mas não na sua implementação ou execução de suas dependências.
O Packagist.org por exemplo, é o repositório padrão do composer. Lá podemos encontrar mais de 300.000 módulos, bibliotecas, frameworks e sistemas prontos para uso. A maioria gratuito e de código aberto.
O composer se encarregará de padronizar e lidar com os diferentes tipos de padrões de classes, e baixar eventuais dependências de cada projeto. Além disso, ele também se encarrega de verificar a compatibilidade entre as dependências, e configurações de seu ambiente.
Você certamente não precisará mais perder tempo desenvolvendo o que já existe e está pronto para uso.
Instalação do composer
A instalação do composer é feita com alguns comandos PHP. Portanto, antes de iniciar sua instalação, certifique-se que você tem o PHP disponível no seu terminal.
As 4 linhas que você digitará para instalar a versão mais recente do composer podem ser encontradas no começo deste artigo. Parte deste comando é atualizada a cada nova versão a fim de verificar a autenticidade do arquivo baixado. Por isso não deixarei o comando por aqui.
Uma vez instalado, você terá poderá digitar composer --version em seu terminal e ver qual versão tem instalada.
Atualização
Para atualizar o composer, basta digitar composer self-update.
Note que este comando atualizará o composer em si e não um projeto e suas dependências. Veremos como fazer isso adiante neste artigo.
O começo – composer require
O comando require é usado sempre que queremos instalar uma dependência em um projeto existente ou mesmo quando iniciamos algum desenvolvimento e precisamos de uma biblioteca externa.
Não importa de você está instalando um novo módulo no Magento 2, usando outro framework PHP qualquer, ou mesmo em um projeto que sequer utilize o composer.
Ao digitar o comando composer require <desenvolvedor/projeto>, o composer buscará este projeto e todas suas dependências no Packagist.
Eventualmente outros repositórios serão buscados se eles estiverem listados previamente no composer.json. Veremos isso adiante quando falar sobre o repositório do Magento.
Em seguida, este projeto será adicionado à pasta /vendor.
Veja um exemplo clássico:
$ composer require monolog/monolog Using version ^2.3 for monolog/monolog ./composer.json has been created Running composer update monolog/monolog Loading composer repositories with package information Updating dependencies Lock file operations: 2 installs, 0 updates, 0 removals - Locking monolog/monolog (2.3.5) - Locking psr/log (1.1.4) Writing lock file Installing dependencies from lock file (including require-dev) Package operations: 2 installs, 0 updates, 0 removals - Downloading psr/log (1.1.4) - Installing psr/log (1.1.4): Extracting archive - Installing monolog/monolog (2.3.5): Extracting archive 11 package suggestions were added by new dependencies, use `composer suggest` to see details. Generating autoload files 1 package you are using is looking for funding. Use the `composer fund` command to find out more!
O monolog é um dos projetos mais antigos e conhecidos no mundo PHP. Trata-se de uma biblioteca completa para “logar” o que você quiser e onde quiser.
Ao digitar o comando acima, o composer criou os arquivos composer.json e composer.lock na pasta raiz. Além disso, também criou a pasta /vendor com o monolog e suas dependências.
.
├── composer.json
├── composer.lock
└── vendor
├── autoload.php
├── bin
├── composer
├── monolog
└── psr
Testando nosso monolog e salvando um arquivo de log
Se desejar testar nosso monolog, crie o arquivo index.php na raiz do projeto com o seguinte conteúdo.
<?php
require 'vendor/autoload.php';
use Monolog\Logger;
use Monolog\Handler\StreamHandler;
// create a log channel
$log = new Logger('magenteiro');
$log->pushHandler(new StreamHandler('teste.log', Logger::WARNING));
// add records to the log
$log->warning('Foo');
$log->error('Bar');
Execute o arquivo com php index.php no seu terminal, e veja que um arquivo teste.log foi criado com nossas mensagens.
Veja alguns dos handlers disponíveis nativamente no Monolog navegando em /vendor/monolog/monolog/src/Monolog/Handler.
Os principais arquivos do composer
Sempre que trabalharmos em um projeto com composer, encontraremos dois arquivos principais na pasta raiz.
composer.json
Este arquivo é responsável principalmente por listar as dependências do projeto e suas versões.
Um exemplo em bom Portugês seria: “composer, este projeto requer Magento 2.4 ou superior, mas não acima do 2.x, mesmo que o 3.0 já esteja disponível”.
Eventualmente ele também pode falar “e exija que o PHP 8.0 ou superior, desde que 8.x, esteja instalado no ambiente, e a lib de conexão com mysql esteja disponível no php”.
Desta forma, se você enviar este arquivo para alguém, a pessoa poderá simplesmente digitar composer install na raiz do projeto para baixar as dependências de acordo com as versões especificadas.
composer.lock
Este arquivo nunca deve ser modificado manualmente. Ele contém informações sobre todas bibliotecas instaladas e a versão exata de cada uma.
Enquanto o composer.json pede “baixe esta dependência em qualquer versão acima da 8.0 mas menor que 9.0”, o composer.json informa que a versão instalada daquela dependência é exatamente a 8.2.9, por exemplo.
Ao existir um arquivo composer.lock, o comando composer install instalará exatamente as versões especificadas ali, ignorando o composer.json.
A presença do composer.lock garante que os arquivos da pasta /vendor de um ambiente serão exatamente idênticos a outro com o mesmo arquivo composer.lock.
No entanto, ao digitar o comando composer update, todas as bibliotecas e suas depenências serão atualizadas para as versões especificadas no composer.json, e provavelmente os arquivos não serão mais iguais.
Pasta /vendor
Como vimos, a pasta vendor (fornecedor) contém todas as bibliotecas e suas dependências, além de um arquivo autoload.php.
Esta é uma pasta que não deve estar presente no controle de versão. Afinal, o composer será responsável por baixar e gerenciar seu conteúdo.
O conteúdo da pasta vendor também nunca deve ser alterado manualmente por nós. Se você precisa corrigir ou modificar uma biblioteca específica, o ideal é que crie um fork da mesma ou mova-a para sua pasta de trabalho deste projeto.
No caso de erros por conta de mudanças inesperadas nesta pasta, é comum removermos a pasta vendor e rodarmos o composer install novamente na raiz de um projeto.
Portanto lembre-se de nunca mexer no conteúdo de sua pasta vendor.
O que versionar
Se você criou um projeto ou biblioteca que deseja distribuir e eventualmente listá-lo no packagist.org, somente o arquivo composer.json é necessário versionar. Veja um exemplo com o composer.json do projeto monolog.
O composer.json sempre será necessário para o composer. Por isso, na minha opinião ele sempre deve ser versionado.
Já o composer.lock traz informações importantes sobre o nosso projeto. A não existência dele ao baixar um projeto versionado pode nos levar a ter arquivos diferentes do de outros desenvolvedores ou mesmo do ambiente de produção. Isso pode trazer consequências e comportamentos inesperados. Por isso, o composer.lock também deve ser versionado.
A pasta /vendor por sua vez, não precisa ser versionada. Afinal, o composer se encarregará de baixar suas dependências.
Dependências, suas versões e constraints
Ao solicitar ou adicionar uma nova dependência ao composer.json, precisamos informar que versão deste pacote desejamos.
As versões disponíveis de um pacote geralmente coincidem com as tags de seu repositório. Estas tags são absorvidas pelo Packagist e listadas na página do pacote. Veja um exemplo:
Ao chamar o comando composer require monolog/monolog podemos acrescentar a versão que desejamos ou uma constraint que informa o intervalo de versões que desejamos.
Veja alguns exemplos:
- composer require monolog/monolog 2.3.5 – a versão 2.3.5 será instalada, mesmo que uma mais recente esteja disponível
- composer require monolog/monolog ^2.2 – qualquer versão igual ou mais recente que a 2.2.0, mas menor que 2.3.0 será instalada. Ex: 2.12.0, 2.2.5, 2.2.8, 2.2.0
- composer require monolog/monolog 2.* – a mais recente versão que comece com 2 será instalada
Quer testar isso na prática? Conheça o Semver Checker MadeWithLove e teste a constraint de uma versão, para ver quais opções estarão disponíveis.
Não tem um repositório, mas quer testar para saber se uma versão será atendido por sua constraint? Sem problemas. Use o Semver check do Jubianchi então.
Além de testar se a constraint informada atende aquela versão, ele ainda dá uma mini aula sobre o assunto.
Semantic versioning
O uso de constraints é recomendado quando adicionamos dependências. Se todos seguirem as boas práticas, uma atualização 2.4.3 para 2.4.4 de um componente não será um problema. No entanto, é esperado que não haja compatibilidade entre uma atualização 2.4.4 para 3.0.0.
Parafraseando a definição do versionamento semântico, a regra seguiria da seguinte forma:
Dado um número de versão MAJOR.MINOR.PATCH, incremente a:
1. versão Maior(MAJOR): quando fizer mudanças incompatíveis na API,
2. versão Menor(MINOR): quando adicionar funcionalidades mantendo compatibilidade, e
3. versão de Correção(PATCH): quando corrigir falhas mantendo compatibilidade.
Rótulos adicionais para pré-lançamento(pre-release) e metadados de construção(build) estão disponíveis como extensão ao formato MAJOR.MINOR.PATCH.
Você pode ler a documentação completa do versionamento semântico para versionar seus projetos com eficiência. Ela está disponível também em Português.
O composer do Magento
Módulos, temas e pacotes de tradução também são instalados com composer no Magento.
No entanto, além do Packagist, o Magento dá preferência ao seu repositório privado. Para acessá-lo é necessário obter suas chaves no Marketplace. Mostramos isso no artigo sobre Como instalar o Magento 2 usando composer.
Uma vez que você compra um módulo ou tema no marketplace da Adobe, o produto fica disponível em sua conta. E caso seu Magento tenha sido instalado com composer, você poderá usar o comando composer require + nome do componente e opcionalmente a constraint de versão que desejar.
Gostou deste artigo? Não esqueça de comentar e compartilhar.
Muito mais do que isso é ensinado nos nossos cursos por aqui. Fique ligado(a).
- PagSeguro (PagBank) para Magento 1 recebe a Nova Geração - 9 de abril de 2024
- Recorrência no WooCommerce Sem Plugins Pagos - 28 de janeiro de 2024
- Chargeback. O que é, e como se livrar deles. - 19 de dezembro de 2023
Deixe seu comentário
[fbcomments url="https://www.magenteiro.com/blog/para-magenteiros/composer-um-jeito-simples-de-entender/"]