Anteriormente neste capítulo, usamos o Composer para instalar as biblioteca do Zend Framework 3. Agora vamos mostrar brevemente alguns exemplos avançados de uso do Composer.
Como já sabemos, a única chave obrigatória no arquivo composer.json
é a require
. Esta chave
informa quais pacotes são necessários para a sua aplicativo:
{
"require": {
"php": "^5.6 || ^7.0",
"zendframework/zend-component-installer": "^1.0 || ^0.3 || ^1.0.0-dev@dev",
"zendframework/zend-mvc": "^3.0.1",
"zfcampus/zf-development-mode": "^3.0",
"zendframework/zend-mvc-form": "^1.0",
"zendframework/zend-mvc-plugins": "^1.0.1",
"zendframework/zend-session": "^2.7.1"
}
}
Um pacote consiste em duas partes: o nome do vendor e o nome do projeto. Por exemplo O nome do pacote "zendframework/zend-mvc" consiste no nome do vendor "zendframework" e o nome do projeto "zend-mvc". Você pode procurar outros pacotes de "zendframework" através do site Packagist.org (veja a imagem 2.8 para um exemplo).
Um pacote também possui um número de versão associada a ele. Um número de versão consiste em um número maior ou menor
número de compilação. Dentro da chave require
podemos especificamos qual versões do pacote são desejamos.
Por exemplo, se digitarmos "^5.6" significa que podemos instalar versões maiores que "5.6", e menores que "6.0"
(Caso quisermos podemos instalar somente aqueles pacotes que não afetem a compatibilidade com versões anteriores).
Na tabela 2.2, são apresentadas possíveis maneiras de especificar versões:
Exemplo | Descrição |
---|---|
3.0.1 | Versão exata. Neste exemplo, apenas a versão 3.0.1 pode ser instalada. |
>=3.0.1 | Maior ou Igual a versão poderá ser instalada.(3.0.1, 3.2.1, etc.) |
>3.0.1 | Versões maiores que podem ser instaladas. (3.0.2 etc.) |
<=3.0.1 | Versão menor ou igual pode ser instalada (1.0, 1.5, 2.0.0 etc.) |
<3.0.1 | Versão inferior pode ser instalada (1.0, 1.1, 1.9, etc.) |
!=3.0.1 | Todas as versões, exceto esta versão, podem ser instaladas. |
>=3.0,<3.1.0 | Qualquer versão entre essa faixa de versões pode ser instalada. |
3.* | Qualquer versão com um número maior ou igual a 3 pode ser instalada |
~3.0 | Qualquer versão a partir de 3.0, mas menor que a próxima versão principal (equivale a >=3.0,<4.0). |
^3.0 | Qualquer versão a partir de 3.0, mas menor que a próxima versão principal (equivalente a> = 3.0, <4.0). Semelhante ao ~3.0 . |
Nós vimos como usar o comando php composer.phar install
para instalar nossas dependências.
Assim que você executa o comando, o Composer vai, baixar e instalar as dependências
para o seu subdiretório vendor
.
É seguro instalar dependências com o Composer?
Bem, algumas pessoas podem ter medo receio do estilo de gerenciamento do Composer, Porque acham que alguém pode atualizar todo o sistema por engano ou até intencionalmente, fazendo com que o aplicativo da web seja pare de funcionar . Note que o Composer nunca instala estes arquivos no sistema, em vez disso, instala-os no diretório
APP_DIR/vendor/
.
Agora suponhamos que que após certo tempo novas atualizações de segurança para seus pacotes de dependência sejam liberadas. Você vai querer atualizar seus pacotes para manter seu site seguro. Você pode fazer isso digitando o seguinte:
php composer.phar update
Se você deseja atualizar apenas uma única dependência, digite seu nome da seguinte forma:
php composer.phar update zendframework/zend-mvc
Após o comando update
, seu arquivo composer.lock
será atualizado também.
O que faço se eu quiser voltar para a versão anterior do pacote?
Se o procedimento de atualização resultou em problemas indesejados com o seu sistema, você pode reverter revertendo as mudanças do seu arquivo
composer.lock
digitando comandoinstall
novamente. A alterações nocomposer.lock
é fácil se você usar um sistema de controle de versão, como o GIT ou o SVN. Se você não usa um sistema de controle de versão, faça um backup docomposer.lock
antes de atualizar.
Se você quiser adicionar nova dependência a sua aplicação, você pode editar composer.json
manualmente, ou execute o comando require
. Por exemplo, para instalar o módulo Doctrine ORM em seu site
site (para adicionar o pacote "doctrine/doctrine-module" a sua aplicação), digite o seguinte:
php composer.phar require doctrine/doctrine-module 2.*
O comando acima edita o arquivo composer.json
e faz o download e instala o pacote. Nós vamos usar este comando
mais adiante no capítulo Gerenciando Banco de Dados com Doctrine, quando estivermos familiarizado
com o banco de dados.
O Composer pode ser usado para exigir algumas funcionalidades do seu sistema. Você já viu como precisamos "php:^5.6". O pacote PHP é uma virtual Package representando o próprio PHP. Você também pode exigir outras coisas, como extensões PHP (veja a tabela 2.3 abaixo).
Exemplo | Descrição |
---|---|
"php":"^5.6" | Requer a versão do PHP maior ou igual a 5.6 porém menor que a 6.0. |
ext-dom, ext-pdo-mysql | Requer as extensões PHP DOM e PDO MySQL. |
lib-openssl | Requer a blibioteca OpenSSL. |
Você pode executar o comando php composer.phar show --platform
para exibir a lista de pacotes disponíveis
para a sua máquina.
Se você estiver usando um sistema de controle de versão (como o Git), deve está curioso
sobre o que deve ser armazenado no Git: apenas o codigo da sua aplicação ou o código do seu aplicativo
mais todas as dependências que foram instaladas pelo Composer no diretório APP_DIR/vendor
?
Geralmente, não é recomendado armazenar suas dependências do Composer
sob controle de versão, porque isso pode tornar seu repositório muito grande e lento para fazer check-out.
Em vez disso você deve armazenar seu arquivo composer.lock
no seu controle de versão. O arquivo
composer.lock
garante que instalem as mesmas versões de dependências que você possuia.
Isso é útil em equipes de desenvolvimento com mais de um desenvolvedor, porque todos
os desenvolvedores devem ter o mesmo código para evitar problemas indesejados com o ambiente
configuração incorreta.
E se alguma dependência se tornar obsoleta ou for removida da Packagist.org?
Bem, a possibilidade de remoção de pacotes é mínima. Todos os pacotes são gratuitos e de código aberto, e a comunidade de usuários sempre pode restaurar a dependência, mesmo se ela for removida do packagist. O mesmo conceito de instalação de dependência é usado no Linux (lembra APT ou RPM manager?), você já viu algum pacote Linux perdido?
Mas pode haver situações em que você deve armazenar algumas bibliotecas dependentes sob controle de versão:
Se você tiver feito uma alterações no código de terceiros. Por exemplo, suponha você tem que consertar um bug em uma biblioteca, e você não pode esperar pelo fornecedor da biblioteca para corrigi-lo para você (ou se o fornecedor da biblioteca não puder consertar o bug). Nesse caso, você deve colocar o código da biblioteca sob controle de versão para garantir o seu as mudanças não serão perdidas.
Se você escreveu um módulo ou biblioteca reutilizável e deseja armazená-lo no `vendor' sem publicá-lo em Packagist.org.
Se você quiser uma garantia de 100% de que um pacote não será perdido. Embora o risco seja mínimo, para algumas aplicações é essencial ser autônomo e não depender da disponibilidade do pacote no Packagist.org.