capa-post-packgist-php-composer-repositorio-astronauts-developers

Packagist – Repositório do Composer PHP

Packagist é o principal repositório do Composer. Ele agrega pacotes PHP públicos instaláveis ​​com o Composer. Então venha conosco neste post e entenda de forma bem inteligente como funciona essa linda comunidade.

VEJA TAMBÉM:

O que é Packagist?

logo small
Packagist.org

Packagist é o repositório de pacotes padrão do Composer. Ele permite que você encontre pacotes e que o Composer saiba de onde obter o código. Você pode usar o Composer para gerenciar seu projeto ou dependências de bibliotecas – leia mais sobre isso no site do Composer.

Você pode encontrar a fonte packagist.org no GitHub. Além de manter uma comunidade incrível de componentes para soluções rápida para desenvolvedores PHP.

Compreenda toda a comunidade em alguns tópicos que separamos para você matar as curiosidades!

Comunidade do Packagist

Se você tiver dúvidas sobre o compositor ou quiser ajudar, junte-se a nós no canal #composer em irc.freenode.net. Você pode encontrar mais recursos da comunidade na documentação do Composer.

Contribuindo / Doando

Para relatar problemas ou contribuir com código, você pode encontrar o repositório de origem no GitHub .

Se você deseja apoiar financeiramente a hospedagem e manutenção do projeto, a melhor forma é fazer o check-out e usar o Private Packagist. Ele pode ajudá-lo a instalar pacotes de forma rápida e confiável, fornece um repositório de pacotes privado e o dinheiro vai para a manutenção do Composer e do Packagist!

Como enviar pacotes para o Packagist?

Nomeando seu pacote

Em primeiro lugar, você deve escolher um nome de pacote. Esta é uma etapa muito importante, pois não pode ser alterada e deve ser exclusiva o suficiente para evitar conflitos no futuro.

O nome do pacote consiste em um nome de fornecedor e um nome de projeto unidos por um /. O nome do fornecedor existe para evitar conflitos de nomenclatura. Por exemplo, incluindo um nome de fornecedor, igorwseldaekpode ter uma biblioteca nomeada jsonnomeando seus pacotes igorw/jsonseldaek/json.

Em alguns casos, o nome do fornecedor e o nome do pacote podem ser idênticos. Um exemplo disso seria `monolog / monolog`. Para projetos com um nome exclusivo, isso é recomendado. Também permite adicionar mais projetos relacionados sob o mesmo fornecedor posteriormente. Se você estiver mantendo uma biblioteca, isso tornaria muito fácil dividi-la em partes menores desacopladas.

Aqui está uma lista de nomes de pacotes típicos para referência:

// Monolog is a library, so the vendor name and package name are the same.
monolog/monolog

// That could be the name of a drupal module (maintained/provided by monolog,
// if the drupal team did it, the vendor would be drupal).
monolog/monolog-drupal-module

// Acme is a company or person here, they can name their package with a common name (Email).
// As long as it's in their own vendor namespace it does not conflict with anyone else.
acme/email

Os nomes dos fornecedores no packagist são protegidos assim que um pacote com aquele nome for publicado. Isso significa que você não pode publicar pacotes com um nome de fornecedor que já existe no packagist sem permissão. Para poder publicar pacotes para um nome de fornecedor já existente, você precisa ser o mantenedor de pelo menos um pacote desse fornecedor.

Gerenciando versões de pacote no Packagist!

Novas versões de seu pacote são obtidas automaticamente de tags que você cria em seu repositório VCS.

A maneira mais fácil de gerenciar o controle de versão é apenas omitir o campo de versão do arquivo composer.json. Os números de versão serão analisados ​​a partir dos nomes de tag e ramificação.

Os nomes de tag / versão devem corresponder a ‘XYZ’ ou ‘vX.Y.Z’, com um sufixo opcional para versões RC, beta, alfa ou patch. Aqui estão alguns exemplos de nomes de tag válidos:

1.0.0
v1.0.0
1.10.5-RC1
v4.4.4beta2
v2.0.0-alpha
v2.0.4-p1

Ramificações aparecerão automaticamente como versões “dev” que podem ser facilmente instaladas por qualquer pessoa que queira experimentar as melhores e mais recentes versões de sua biblioteca, mas isso não significa que você não deve marcar lançamentos. O uso de Versão Semântica é fortemente encorajado.

Criação de um arquivo composer.json

Private Packagist logo, a paper elephant and the text reads: Private Packagist
Composer – Gerenciador de Dependências do PHP

O arquivo composer.json deve residir no topo do repositório git / svn / .. de seu pacote, e é a maneira como você descreve seu pacote para packagist e composer.

Um arquivo composer.json típico se parece com isto:

{
    "name": "monolog/monolog",
    "type": "library",
    "description": "Logging for PHP 5.3",
    "keywords": ["log","logging"],
    "homepage": "https://github.com/Seldaek/monolog",
    "license": "MIT",
    "authors": [
        {
            "name": "Jordi Boggiano",
            "email": "[email protected]",
            "homepage": "http://seld.be",
            "role": "Developer"
        }
    ],
    "require": {
        "php": ">=5.3.0"
    },
    "autoload": {
        "psr-0": {
            "Monolog": "src"
        }
    }
}

Muitas dessas informações são óbvias, palavras-chave são tags, requerem uma lista de dependências que seu pacote possui. É claro que podem ser pacotes, não apenas uma versão php. Você pode usar ext-foo para exigir extensões php (por exemplo, ext-curl). Observe que a maioria das extensões não expõe informações de versão, portanto, a menos que você tenha certeza disso, é mais seguro usar "ext-curl": "*"para permitir qualquer versão dela. Finalmente, o campo tipo neste caso indica que se trata de uma biblioteca. Se você fizer plug-ins para frameworks, etc, e se eles integrarem o composer, eles podem ter um tipo de pacote personalizado para seus plug-ins que você pode usar para instalar o pacote com seu próprio instalador. Na ausência de um tipo personalizado, você pode omiti-lo ou usar “biblioteca”.

Depois de ter esse arquivo confirmado na raiz do repositório, você pode enviar o pacote ao Packagist inserindo a URL do repositório público.

Cronograma de atualização

Novos pacotes serão rastreados imediatamente após o envio, se o JS estiver ativado.

Os pacotes existentes sem atualização automática (gancho GitHub / BitBucket) serão rastreados uma vez por semana para atualizações. Quando um gancho está ativado, os pacotes são rastreados sempre que você empurra, ou pelo menos uma vez por mês, caso o rastreamento falhe. Você também pode acionar uma atualização manual na página do pacote se estiver conectado como mantenedor.

É altamente recomendável configurar o gancho de serviço GitHub / BitBucket para todos os seus pacotes. Isso reduz a carga do nosso lado e garante que seu pacote seja atualizado quase que instantaneamente. Verifique as instruções abaixo .

O índice de pesquisa é atualizado a cada cinco minutos . Ele irá indexar (ou reindexar) qualquer pacote que foi rastreado desde a última vez que o indexador de pesquisa foi executado.

Como atualizar pacotes?

GitHub Hook

Habilitar o gancho de serviço Packagist garante que seu pacote sempre será atualizado instantaneamente quando você enviar para o GitHub.

Para fazer isso, você pode:

  • Certifique-se de fazer o login via GitHub (se você já tem uma conta não conectada ao GitHub, você pode conectá-la em seu perfil ). Se você já estiver logado, saia primeiro e, em seguida, faça o login via GitHub novamente para garantir que nos concedeu as permissões necessárias.
  • Certifique-se de que o aplicativo Packagist tenha acesso a todas as organizações GitHub das quais você precisa publicar pacotes.
  • Verifique sua lista de pacotes para ver se há algum aviso sobre não ser sincronizado automaticamente.
  • Se você ainda precisa configurar a sincronização em alguns pacotes, tente acionar uma sincronização manual da conta para que o Packagist tente configurar ganchos em sua conta novamente. Observe que os repositórios arquivados não podem ser configurados, pois são somente leitura na API do GitHub.

Não deseja fazer login pelo GitHub e nos conceder acesso à configuração do webhook?

Você pode configurar um webhook GitHub manualmente usando os seguintes valores:

  • URL de carga útil: https://packagist.org/api/github?username=PACKAGIST_USERNAME
  • Tipo de conteúdo: application/json
  • Segredo: seu token Packagist API
  • Quais eventos? Apenas o pushevento é o suficiente.

Serviço GitLab

Para habilitar a integração do serviço GitLab, vá para o seu repositório GitLab, abra a página Configurações> Integrações no menu. Procure Packagist na lista de Project Services. Marque a caixa “Ativo”, digite seu nome de usuário packagist.org e token de API. Salve suas alterações e pronto.

Bitbucket Webhooks

Para habilitar o web hook do Bitbucket, vá até o repositório do BitBucket, abra as configurações e selecione “Webhooks” no menu. Adicione um novo gancho. Você deve inserir o endpoint Packagist, contendo seu nome de usuário e token API. Insira https://packagist.org/api/bitbucket?username=USERNAME&apiToken=API_TOKENcomo URL. Salve suas alterações e pronto.

Configuração manual do gancho

Se você não usa Bitbucket ou GitHub, há um endpoint genérico que você pode chamar manualmente de um gancho git post-receive ou similar. Você deve fazer uma POSTsolicitação https://packagist.org/api/update-package?username=USERNAME&apiToken=API_TOKENcom um corpo de solicitação parecido com este:{"repository":{"url":"PACKAGIST_PACKAGE_URL"}}

Você pode fazer isso usando curl, por exemplo:

curl -XPOST -H'content-type: application / json '' https://packagist.org/api/update-package?username=USERNAME&apiToken=API_TOKEN '-d' {"repository": {"url": "PACKAGIST_PACKAGE_URL "}} '

Token API

Você pode encontrar seu token de API em sua página de perfil. Uma comunidade toda componentizada seguindo padrões de desenvolvimento.

Agora o PHP além de ter um gerenciador de pacotes incrível, você pode utilizar o composer para baixar esses componentes e integrar á sua aplicação de forma rápida e padronizada, facilitando a criação e mantendo as regras e padrões da comunidade.

E você não precisará se preocupar com a atualizações do seu código, pois a comunidade do packagist está sempre mantendo os componentes com novas versões e integrado ao github ou gitlab. Quer saber mais sobre PHP do Jeito Certo? Acompanhe nossa matéria explicativa!

Explore todo o browser de busca, que listará para você todos os repositórios de componentes da comunidade e totalmente livre. Reutilize em seus projetos e colabore sempre.

Gostou deste conteúdo? Deixe o seu melhor comentário.

Até a próxima!

Comentários encerrados.

OnlyFans Brasil: Descubra as Brasileiras que Lucram com a Rede Social! AS MODELOS MAIS SOLICITADAS DO ONLYFANS AS TOP 5 TIKTOKERS MAIS QUENTES Perfis que bombam no OnlyFans e Privacy