README

Como iniciar o composer no projeto

• composer init
• responder quem está (distribuindo/nome-do-pacote)
• colocar descrição
• responder quem é o autor(es)
• se quer pacote em fase de teste ou estáveis (ex: stable, dev)
• tipo de pacote (geralmente library)
• tipo de licença (ex: mit)

Entendendo o arquivo composer.json

• name é o nome do pacote (vendor/nome)
• description descrição do pacote
• type tipo do pacote (library, project)
• autoload configuração de carregamento automático de classes
• authors autor/autores do pacote
• require dependências do pacote

{
    "name": "edilsonjrdev99/buscador-items-alura",
    "description": "Projeto teste referente a aula sobre composer da Alura, lib para buscar os items de um HTML de site",
    "type": "library",
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "authors": [
        {
            "name": "edilson junior",
            "email": "edilsonjrdev99@gmail.com"
        }
    ],
    "require": {
        "guzzlehttp/guzzle": "^7.10",
        "symfony/dom-crawler": "^8.0",
        "symfony/css-selector": "^8.0"
    }
}

Onde buscar dependências

Atenção: O Packagist é o repositório padrão para buscar dependências para o composer, mas podemos configurar ele para buscar do github

Basta acessar: Packagist

O que acontece quando instalamos uma dependência

O composer vai no Packagist, vai verificar se o pacote existe, se existir no pacote tem a definição do código fonte, que é de onde ele vai buscar o código, por padrão ele busca do github

Diferença entre comandos

• composer require pacote Isso adiciona o pacote na dependência do composer.json, instala o pacote e atualiza o composer.lock também

• composer update pacote Isso vai atualizar o pacote já existente nas dependências do composer.json, respeitendo suas restrições ex: "guzzlehttp/guzzle": "^7.10", vai baixar somente versão acima de 7.10 e atualizar também no composer.lock, é importante não usar apenas composer update, isso vai atualizar todas as dependências e causar erro no projeto

Entenendo o autoload

O autoload é responsável por definir mapeamento de arquivos, ele está presente no composer.json. No autoload podemos utilizar duas PSRs, a psr-0 que já está deprecida e a psr-4 que é a convencional atual.

• psr-4: possui um vendor namespace que é namespace padrão da aplicação, o namespace representa a pasta principal do projeto. No exemplo abaixo definimos que App representa a pasta src.

"autoload": {
    "psr-4": {
        "App\\": "src/"
    }
},

Arquivo fica em src/ClassExample.php

<?php

namespace App/ClassExample;

class ClassExample {

}

• classMap: cria um mapeamento de uma classe, ela não vai precisar usar namespace e para cria é simples, adicione dentro de autoload no arquivo de composer.json o campo é classmap e o valor é um array com os caminhos dos arquivos

"autoload": {
        "classmap": [
            "./Test.php"
        ]
    },

importante; ao adicionar o classmap no composer.json e rodar o comando de composer dump-autoload ele vai gerar um mapeamento das classes em vendor/autoload_classmap.php

composer/autoload_classmap.php

<?php

// autoload_classmap.php @generated by Composer

$vendorDir = dirname(__DIR__);
$baseDir = dirname($vendorDir);

return array(
    'Composer\\InstalledVersions' => $vendorDir . '/composer/InstalledVersions.php',
    'Test' => $baseDir . '/Test.php',
);

• files: É utilizado para carregar aquivos, não precisa ser arquivo de classe, geralmente utilizado para mapear arquivo com funções.

"autoload": {
        "files": [
            "./functions.php"
        ]
    },

Diferenças entre os 3 tipos: O recomendado para usar atualmente é a psr-4, ele cria um mapeamento do namespace com pastas e carrega as classes automaticamente quando usadas. O classmap é menos performático do que o psr-4 porque ele precisa procurar a classe no mapa e é utilizado para classes legado que não podem implementar a psr-4. O files deve ser usado com cuidado porque ele vai sempre carregar os arquivos, se o arquivo mapeado tiver funções pesadas isso pode prejudicar a performance do projeto.

Dependências apenas para desenvolvimento

Podemos definir que algumas libs vão ser utilizadas somente em ambiente de desenvolvimento, para isso usamos a flag --dev, agora para definirmos que vamos instalar somente as dependências que não são dev usamos a flag composer install --no-dev

Exemplo de um comando de uma ferramenta que utilizamos somente em ambiente de desenvolvimento: composer require --dev phpunit/phpunit ^13

Arquivos executáveis do composer

Quando alguma lib possui um arquivo executável, como o caso do PHP Unit esses arquivos ficam em vendor/bin/arquivo.php e podemos executalos com: php vendor/bin/arquivo-executavel --parametro

php vendor/bin/phpunit --version
php vendor/bin/phpcs --standard=PSR12 src/

Dicas de libs

• squizlabs/php_codesniffer: Verifica qualidade do código de acordo com algum padrão, por exemplo psr12

# instalação
composer require --dev squizlabs/php_codesniffer

# define padrão e pasta onde ele deve verificar
php vendor/bin/phpcs --standard=PSR12 src/ 

• phan/phan: Verifica se existe algum erro ou bug no código

# intalação
composer require --dev phan/phan

# rodando o phan direto pelo terminal
php vendor/bin/phan --allow-polyfill-parser -d src

# rodando com o arquivo de .phan/config
php vendor/bin/phan --init
php vendor/bin/phan

Como criar scripts para rodar comandos no composer

Para criar scripts no composer.json é simples, basta adicionar o campo de scripts e dentro dele definir o nome do script e o comando que ele vai executar, um ponto interessante é que arquivos executáveis do vendor/bin não precisamos definir, ele encontra automaticamente

"scripts": {
    "test-version": "phpunit --version",
    "phpcs": "phpcs --standard=psr12 src || true",
    "phan": "phan --init"
},

Como rodar os comandos

composer test-version

Como criar um script responsável por executar vários scripts do composer.json: Basta criar um script novo e no seu valor adicionar um array com os nomes dos scripts, é importante usar o @ para referenciar o script, exemplo:

"check": [
    "@test-version",
    "@phpcs",
    "@phan"
]

Como adicionar descrição dos scripts

Basta adicionar o campo scripts-descriptions e colocar o nome do script e sua descrição, exemplo:

"scripts-descriptions": {
    "test-version": "Script que retorna a versão do PHP Unit",
    "phpcs": "Script responsável por verificar se existe erros de padrões de código de acordo com a PSR12",
    "phan": "Script responsável por iniciar a config da ferramenta que verifica erros de código Phan",
    "check": "Script que executa os scripts de test-version, phpcs e phan"
},

Tipos de eventos no composer

Para definir um evento, por exemplo rodar um script após um composer update, basta adicionar um evento dentro do laço de script, os tipos de eventos estão na referência abaixo

"scripts": {
    "test-version": "vendor/bin/phpunit --version",
    "phpcs": "phpcs --standard=psr12 src || true",
    "phan": "phan --init",
    "check": [
        "@test-version",
        "@phpcs",
        "@phan"
    ],
    "post-update-cmd": [
        "php index.php"
    ]
},

Eventos do composer

Entendendo como versionar um projeto

A versão é separada por 3 tipos:

Exemplo: 1.2.3

1. MAJOR: Quando a atualização faz uma alteração de compatibilidade, que pode quebrar o código de quem está na versão antiga, você deve versionar a MAJOR, exemplo alterar um retorno de array para Collection, alteramos o primeiro número, no caso o 1.2.3 para 2.2.3

2. MINOR: Quando adicionamos algo novo e mantemos tudo o que já existe funcionando alteramos o segundo valor, 1.2.3 para 1.3.3

3. PATCH: Quando acontece alguma correção de bug ou uma alteraçãozinha, mudamos o terceiro 1.2.3 para 1.2.4