A esta altura do campeonato, para trabalhar com PHP muito provavelmente você já está usando Composer, certo? Certo!
O Composer, para a maioria dos casos, funciona muito bem com seu uso básico. Mas existem alguns macetes do Composer bastante úteis que, certamente, ajudarão com seu workflow de desenvolvimento PHP.
Atualizar somente 1 vendor
Se for preciso atualizar apenas uma dependência específica, sem atualizar todas as outras, isso é fácil com o Composer. Basta adicionar o nome do vendor como argumento para o comando update:
|
1 |
$ composer update foo/bar |
Isso só vai instalar ou atualizar aquela dependência específica (mais suas dependências, se necessário) e substituir o composer.lock.
Fazer isso também é útil para consertar um aviso que pode aparecer em nossos terminais:
|
1 |
Warning: The lock file is not up to date with the latest changes in composer.json, you may be getting outdated dependencies, run update to update them. |
Se você já foi um dos desafortunados que leu essas palavras, deve ter pensando “Mas o que há de errado com minhas dependências?”. Isso acontece quando você edita seu arquivo composer.json. Por exemplo, se você adiciona ou edita algum detalhe — descrição, autores, parâmetros extras ou até mesmo algum espaço em branco –, isso muda o md5sum do arquivo. Então o Composer avisa que o hash difere do composer.lock.
Mas como proceder? O comando update é o que atualiza o arquivo .lock, mas pode haver o caso em que você adicionou alguma informação e não quer atualizar qualquer dependência. Para estes casos, basta executar:
|
1 |
$ composer update --lock |
Adicionar dependência sem editar composer.json
Para adicionar uma nova dependência ao seu projeto, você pode manualmente adicionar uma linha no seu composer.json e usar o método que acabou de ser mostrado para instalar somente aquele pacote. Mas existe uma maneira mais fácil de se fazer isso.
O comando require serve para estas ocasiões:
|
1 |
$ composer require "foo/bar:1.0.0" |
Ele também pode ser usado para iniciar um novo projeto rapidamente. O comando init, acompanhado da opção --require, criar o arquivo composer.json com o(s) pacote(s) especificado(s):
|
1 2 3 4 5 6 7 |
$ composer init --require=foo/bar:1.0.0 -n $ cat composer.json { "require": { "foo/bar": "1.0.0" } } |
Note a opção -n, que serve para não fazer quaisquer perguntas interativa enquanto o Composer trabalha.
Fork fácil
Falando na criação automática do composer.json, você conhece o comando create-project?
|
1 |
$ composer create-project doctrine/orm path 2.2.0 |
Isso clona automaticamente o repositório e faz o checkout da versão especificada. Usar isso torna-se bastante útil para clonar rapidamente uma biblioteca sem ter que procurar o URI através dos fontes.
Cache de pacotes dist
Pacotes dist são cacheados no seu diretório home — levando em conta que você não é um garoto e trabalha num sistema *NIX. Composer automaticamente salva os arquivos quando você usa um pacote dist. Por padrão, pacotes dist são usados para versões com tags (ex.: “symfony/symfony”: “v2.1.4”) ou versões com coringa ou range (exs.: “2.1.*” e “>=2.2,<2.3-dev") se você usa "stable" no minimum-stability.
Mas pacotes dist também podem trabalhar com branches (ex.: dev-master), tal como o GitHub permite baixar de uma referência git. Para forçar o download de um arquivo — não no sentido de “file”, mas de algo armazenado — ao invés de clonar fontes, use a opção --prefer-dist, incluída nos comandos install e update.
Eis uma demonstração (usando a opção --profile para mostrar o tempo de execução):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
$ composer init --require="twig/twig:1.*" -n --profile Memory usage: 3.94MB (peak: 4.08MB), time: 0s $ composer install --profile Loading composer repositories with package information Installing dependencies - Installing twig/twig (v1.12.2) Downloading: 100% Writing lock file Generating autoload files Memory usage: 10.13MB (peak: 12.65MB), time: 4.71s $ rm -rf vendor $ composer install --profile Loading composer repositories with package information Installing dependencies from lock file - Installing twig/twig (v1.12.2) Loading from cache Generating autoload files Memory usage: 4.96MB (peak: 5.57MB), time: 0.45s |
Então, o arquivo para twig/twig:1.12.2 foi salvo em ~/.composer/cache/files/twig/twig/1.12.2.0-v1.12.2.zip e usado na segunda vez em que o pacote foi requisitado.
Fonte para editar vendors
Por razões práticas, você pode preferir clonar fontes (sources) ao invés de baixar pacotes. Por exemplo, isso pode ser útil para editar uma biblioteca diretamente no diretório “vendor” para testar o comportamento da sua aplicação com alguma alteração (ex.: bug fix). A opção --prefer-source força a clonagem de fontes ao invés de baixar através de algo arquivado:
|
1 |
$ composer update symfony/yaml --prefer-source |
Então, para ver os arquivos modificados no seu vendor:
|
1 2 3 4 |
$ composer status -v You have changes in the following dependencies: /path/to/app/vendor/symfony/yaml/Symfony/Component/Yaml: M Dumper.php |
Composer também avisa quando você tenta atualizar um vendor que foi modificado e pergunta se você quer descartar as mudanças:
|
1 2 3 4 5 6 7 |
$ composer update Loading composer repositories with package information Updating dependencies - Updating symfony/symfony v2.2.0 (v2.2.0- => v2.2.0) The package has modified files: M Dumper.php Discard changes [y,n,v,s,?]? |
Esteja pronto para a Produção
Apenas como aviso, antes do deploy do código para o ambiente de Produção, não esqueça de otimizar o autoloader do Composer:
|
1 |
$ composer dump-autoload --optimize |
Isso também pode ser usado enquanto instala pacotes através da opção --optimize-autoloader — sem esta otimização, é possível notar uma diferença de performance de 20~25%.
Estes macetes do Composer, na verdade, podem ser todos encontrados na documentação oficial — e há muita coisa boa no cheatsheet interativo do Composer disponibilizado por JoliCode.
Mas, com certeza, ajuda bastante disponibilizar esses macetes num formato mais amigável, certo? :-)