PHP “like a boss” [1]: Usando Composer

William
phpzm
Published in
6 min readNov 22, 2016

--

Este artigo é parte da série PHP “like a boss”. Recomendo dar uma olhada no artigo de introdução (PHP “like a boss”: Como trabalhar com PHP em 2017) antes de começar este.

Composer é uma ferramenta criada para ser um assistente para o desenvolvedor PHP. Ele começa como um gerenciador de pacotes e vai se estendendo pelo projeto tratando carregamentos de documentos ou armazenando scripts. Acredite, você não vai querer ficar sem ele depois que começar.

Instalação

Comece instalando o composer (http://getcomposer.org) ou apenas faça o download de uma cópia do “.phar” (uma espécie de exe para PHP). Em seguida na raiz do seu projeto execute o comando $ php composer.phar init ou $ composer init (dependendo de como fez a instalação) para configurar um arquivo “composer.json“ para seu projeto.

Não vou detalhar nenhum processo de instalação porque vai depender de muitas variáveis e a documentação do composer é muito clara nesse ponto. No meu ambiente fiz esse processo aqui porque uso Ubuntu. Sempre que ver o “$ composer” daqui para baixo substitua o comando “composer” pela sua forma de usar ; )

Autoload

Crie uma pasta “src“ na raiz do seu projeto. Usando as especificações das PSR-1 e PSR-2 para escrever arquivos e classes, crie uma classe chamada “Connection” no arquivo com mesmo nome “Connection.php” (esse padrão está descrito também nas PSR) dentro da pasta “src”. Em seguida crie um atributo “autoload” no seu arquivo “composer.json” e dentro desse atributo uma propriedade “psr-4”. Esta última deve conter o namespace que foi usado na classe “Connection.php”. No fim teremos dois arquivos como os abaixo.

O objetivo desse procedimento é melhorar o arquivo inicial. Então vamos fazer isso acontecer.

No terminal dê a instrução para seu composer criar o mapeamento de autoload $ composer dump-autoload . Se tudo correr bem irá surgir uma pasta “vendor” na raiz do seu projeto. Dentro dela será criada uma outra pasta chamada “composer”. Abra o arquivo “autoload_psr4.php” e veja se está como a imagem abaixo:

Se estiver assim você mitou! Agora basta usar o seguinte comando “require_once ‘path/to/vendor/autoload.php’;” no lugar do “include ‘conexao.php’;”. Nesse momento você já pode contar pra todo mundo que seu projeto usa composer para carregar sua classe de conexão com banco de dados.

Autoloading Functions

Se você não usa classes por alguma razão (mesmo que religiosa) e prefere usar funções não tem problema! Você perde a vantagem de ter seus documentos carregados progressivamente, será preciso carregar todos de uma vez, mas você pode usar algo como trecho abaixo em seu “composer.json”:

{
(...)
"autoload": {
"files": [
"src/bootstrap.php"
]
},
(...)
}

E criar o “bootstrap.php” parecido com:

<?phpnamespace HeroProject\Functions;if (!function_exists(' HeroProject\Functions\echoThis')) {
/**
* @param $it
*/
function echoThis($it)
{
echo $it;
echo PHP_EOL;
}
}

Sendo assim você pode usar

<?phprequire dirname(__DIR__) . '/vendor/autoload.php';use function HeroProject\Functions\echoThis;echoThis('That all folks!');

Scripts

Você também pode configurar seu “composer.json” para armazenar seus comandos favoritos (aqueles que ficam salvos no bloco de notas).

Note os comandos descritos em “scripts” lá atrás

Instalando Pacotes

O gerenciamento de dependências não é algo novo. Mesmo informalmente ele sempre existiu. Sempre que você usa um fragmento de software pré-definido você passa a ter que lidar com esse trecho do projeto de forma diferente. Uma dependência do seu projeto pode ser criada por você mesmo, e ainda assim você terá de gerenciá-la como uma dependência.

O Composer lida com dependências e permite a você se preocupar com questões menos técnicas e mais arquitetônicas do seu projeto. O repositório oficial do Composer é o packagist.org. E se pesquisar por lá poderá ver vários projetos legais que você pode usar no seu.

A título didático vou demonstrar como adicionar ao nosso projeto uma dependência usando o canal oficial. O pacote escolhido foi esse daqui (https://packagist.org/packages/danielstjules/stringy) e sua escolha está relacionada a simplicidade e documentação razoável. Vamos usar o comando de instalação:

$ composer require danielstjules/stringy

Note que como não há uma declaração da versão depois do nome do pacote a versão mais atual será instalada.

Sintaxe do comando: “composer <require> <vendor/package>[:version]”

Tela do Packagist contendo o comando de instalação

Depois de rodar esse comando no meu terminal na raiz do meu projeto o meu composer.json é modificado. É criada uma nova entrada “require” nele contendo o nome do novo vendor que foi instalado. Uma outra coisa que muda é que surge um “composer.lock” ao lado do “composer.json”. Note que esses dois arquivos devem ser versionados e a pasta “/vendor/” deve ser inclusa a um arquivo “.gitignore” na raiz do projeto.

Se eu tivesse de citar um defeito do Composer seria apenas a demora para ele instalar dependências. Porém se ele fizer direito, não me preocupa muito o tempo que ele demore.

Ao final da instalação o meu terminal fica assim

E o “composer.json” fica assim:

Note também que como o pacote usa PSR-4 a instalação irá atualizar o map de namespaces:

Arquivo “/vendor/composer/autoload_psr4.php”

É isso mesmo que você entendeu! Agora para usar basta você instanciar o objeto do pacote seguindo os namespaces e classes que eles informam na documentação:

Trecho da tela da documentação do Stringy

Com isso nosso podemos atualizar o “index.php” usando os novos recursos:

Criando Pacotes

Se você chegou até aqui e percebeu algum potencial nisso saiba que publicar seu pacote no Packagist é muito simples. Configure seu composer.json para ser um pacote válido parecido com este:

Depois basta criar uma conta no site e chegar até aqui (https://packagist.org/packages/submit) clicando no botão “submit”. Em seguida você add a URL do seu repositório e está pronto!

Depois de criado seu pacote terá uma interface para você parecida com essa:

Onde você pode gerenciar recursos básicos do pacote. Note que quaisquer modificações podem quebrar todo o ecossistema de dependências por isso é preciso comprometimento e seriedade nesse ponto.

Nesse trecho aqui da tela podemos ver detalhes do pacote e o histórico de versões dele:

Para mudar de versão você deve atualizar o “composer.json” e em seguida criar uma tag com essa nova versão. Ao final disso você pode apertar o botão “Update” (o verde) na tela de gestão do pacote.

Uma dica legal para trabalhar no seu pacote é instalar seu pacote em modo “dev-master” no lugar da versão. Dessa forma o Composer já inicializa ele como um repositório para você criando um “remote” chamado “composer”.

$ composer require phpzm/core:dev-master

Observações finais

É claro que nem tudo são flores. Vamos seguir para analisar questões interessantes e que merecem certa atenção.

O Packagist é aberto então esse processo só será válido se você fizer software free. Se quiser proteger alguma propriedade intelectual vai ter que estudar a doc do Composer para ver como proceder com as instalações (na maioria das vezes manuais). Um bom exemplo da própria documentação é esse aqui:

{
"require": {
"vendor/my-private-repo": "dev-master"
},
"repositories": [
{
"type": "vcs",
"url": "git@bitbucket.org:vendor/my-private-repo.git"
}
]
}

O Composer não cria dependências recursivas então problemas de conflitos acontecem quando se combina muitos pacotes sem planejamento.

Você pode remover o pacote do seu projeto usando o comando:

$ composer remove vendor/package

Contudo ele não fará qualquer refatoração no projeto. Use com sabedoria ; )

Sempre que você retoma os trabalhos ou publica um projeto que usa composer você precisa rodar apenas.

$ composer install

Para ter um projeto pronto para uso.

Todos os códigos citados estão aqui https://github.com/phpzm/like-a-boss-1

--

--

Tem algumas coisas que a gente sabe que vão acontecer. Estas são as que acontecem por acaso. Todo o resto é o que compõe a certeza.