No post de hoje vamos mostrar os passos de como publicar um pacote PHP Composer para packagist.org
O que é packagist.org?
Packagist é o principal repositório de pacotes do composer. É aqui que você pode publicar seus pacotes e também onde pode ver os pacotes de outras pessoas. O Composer usará o Packagist para procurar pacotes por padrão, no entanto, usuários mais avançados podem personalizar isso se desejarem. Um motivo pelo qual você pode querer personalizar isso seria usar pacotes privados. Para obter mais detalhes, consulte a documentação do compositor em repositórios .
O que é Composer?
O Composer é um gerenciador de dependências em nível de aplicativo para a linguagem de programação PHP que fornece um formato padrão para gerenciar dependências de software PHP e bibliotecas necessárias. Foi desenvolvido por Nils Adermann e Jordi Boggiano, que continuam a gerenciar o projeto.
1. Sua biblioteca deve conter um composer.json
Ao criar sua biblioteca, execute um composer initpara gerar um composer.jsonarquivo contendo seus detalhes, bem como o nome do fornecedor e o nome da biblioteca do pacote que você publicará no registro do Packagist.
As informações ali contidas, bem como as informações do seu README.mdarquivo (localizado na raiz do seu projeto), serão usadas pelo packagist.org para mostrar as informações sobre sua biblioteca.
2. Conta GitHub (ou outra plataforma de hospedagem git)
Certifique-se de ter uma conta no GitHub (ou em uma plataforma semelhante, como GitLab ou Butbucket).
3. git push para seu repositório Git remoto (por exemplo, GitHub)
Publique seu código no GitHub ou em uma plataforma semelhante (por exemplo, GitLab, Butbucket ou em seu próprio servidor).
4. Crie uma conta no packagist
Você precisará de uma conta no packagist.org para publicar seu pacote.
5. Distribuindo seu pacote via Packagist
Ok, então você está trabalhando em seu novo pacote e deseja publicá-lo para que não apenas possa usá-lo, mas também para que todos possam conferir sua obra! Para publicar seu pacote, visite https://packagist.org/packages/submit e forneça a URL para seu código, seja no GitHub, Bitbucket, Gitlab ou outro.
Você precisará mencionar a URL do repositório. A URL do seu repositório pode ser encontrada na página do repositório da sua plataforma de hospedagem git, na seção “Clone”. parecehttps://github.com/{username}/{project-name}.git
Felizmente, publicar lançamentos de pacotes é muito simples. Tudo o que você precisa fazer é criar uma tag usando git e pronto. Você não deve definir o campo de versão em seu arquivo composer.json.
Se você ainda não criou uma git tag, a versão padrão da sua biblioteca será dev-master.
Depois de criar uma versão git tag (também pode ser feito através do GitHub, Releases -> Draft a new release), a versão será a nova definida como padrão.
Deseja pesquisar pacotes semelhantes e verificar sua própria listagem? Você pode explorar todos os pacotes disponíveis publicamente no site da Packagist.
6. Parabéns! Seu pacote foi publicado np Packagist
Está tudo pronto e sua biblioteca está pronta para ser usada e instalada por qualquer pessoa, simplesmente comcomposer require {your-vendor-name}{your-librar-name}
Licenciamento de pacotes
O campo de licença é opcional, mas é uma boa ideia definir isso para que as pessoas saibam se e como podem usar seu pacote. É um erro comum digitar um nome de licença legível aqui, em vez de um “identificador de licença” real. Se o seu código estiver usando uma licença proprietária, o uso de “proprietary” como identificador de licença também é permitido. Algumas licenças comuns são Apache-2.0, BSD-2-Clause, BSD-3-Clause, GPL-2.0, GPL-3.0 e MIT.
Versões de Desenvolvimento
Então, você está trabalhando em um ótimo novo recurso para seu pacote e deseja testá-lo. Mas há um problema: você deseja carregar suas alterações sem marcar um lançamento porque, naturalmente, ainda não está pronto para um lançamento. Existem algumas abordagens que você pode usar:
- Adicione um alias de ramificação ao seu pacote composer.json,
- Faça referência direta ao nome da ramificação em seu aplicativo composer.json.
Aliases de filial
Isso significa automaticamente que você pode associar uma ramificação a uma versão de pacote de desenvolvimento!
Imagine o caso em que você está trabalhando em uma versão 2.0.0 em sua ramificação master e deseja instalá-la antes de marcar a versão. Uma boa maneira de fazer isso é criar um alias para a ramificação master para a versão “2.0.x-dev”.
Em seu aplicativo, você pode acessar sua versão de desenvolvimento 2.0 usando a restrição de versão “2.0.@dev” ou algo nesse sentido.
Na verdade, o composer é inteligente o suficiente para realmente olhar para o nome do branch e determinar com qual versão ele está associado. Por exemplo, se você nomear um branch como “2.0”, então o composer irá tratá-lo como representando a última versão “2.0.x-dev”.
Por fim, observarei que você pode realmente evitar ter que especificar a estabilidade em suas dependências definindo o seguinte no arquivo composer.json de seu aplicativo:
Isso dirá ao composer que você está feliz por resolver “^2.0” ou “2.0”. para uma versão de desenvolvimento, se necessário, mas você prefere resolver uma versão estável, se puder.
Fazendo referência direta a nomes de filiais
Conforme mencionado, a outra maneira de acessar seu novo código é usar diretamente o nome da ramificação como uma versão. Isso é muito útil quando você está trabalhando em um novo recurso específico, em vez de querer testar algumas alterações mescladas. Para instalar uma ramificação chamada “new-feature”, você precisará da restrição de versão “dev-new-feature”.