Por que include um arquivo composer.json com meu plugin?

Qual é a vantagem de include explicitamente um arquivo composer.json no meu plugin se os usuários potenciais do meu plugin já podem obtê-lo como um pacote através do WPackagist?

Solutions Collecting From Web of "Por que include um arquivo composer.json com meu plugin?"

TL; DR

Se você quiser apoiar o Composer, adicionar um composer.json é melhor, então, deixe WPackagist criar um pacote para você.

Há várias razões, ninguém é realmente importante, mas considerando que criar um composer.json não exige muito esforço, provavelmente vale a pena.

Benefícios do composer.json

Abaixo de uma lista não exaustiva de benefícios de usar composer.json .

Desenvolvedor amigável

Quando você exige um pacote, o Composer olha para os repositorys para encontrar esse pacote específico. Packagist e WPackagist são 2 repositorys.

A diferença é que o Packagist é sempre analisado pelo Composer, enquanto o WPackagist deve ser adicionado manualmente ao projeto composer.json .

Para exigir um plugin no Packagist, você precisa de uma única linha no composer.json :

 "require": { "your-name/your-plugin-name":"1.*", } 

Para exigir um plugin no WPackagist, você precisa também configurar repositorys:

 "repositories":[ { "type":"composer", "url":"http://wpackagist.org" } ], "require": { "your-name/your-plugin-name":"1.*", } 

Isso também é relevante ao usar a linha de comando, veja

 composer create-project your-name/your-plugin-name 

VS

 composer create-project wpackagist-plugin/your-plugin-name --repository-url=http://wpackagist.org 

atuação

Quando um projeto contém mais repositorys, o Composer faz com que todos eles encontrem informações sobre pacotes.

Então, adicionando o repository WPackagist, retarda a instalação. Considere também que todos os servidores podem estar baixos, para qualquer ressonância. Acontece para empresas muito maiores do que a que está por trás do WPackagist, então cada repository que você adiciona, é um ponto de falha adicional possível.

Configuração

Sobre as vantagens de ter um composer.json é que você pode configurar a forma como o Composer irá buscar seu plugin.

Por exemplo, você pode usar configurar o nome do pacote na propriedade do name , em vez de permitir que o WPackagist crie o nome do pacote para você.

Além disso, há muita configuração que pode ser feita em composer.json , apenas alguns exemplos:

  • você pode usar a configuração de branch-alias para melhorar a compatibilidade da versão de desenvolvimento do plugin
  • mesmo se você não possui dependencies, você pode usar a configuração de requisição para definir uma versão mínima do PHP,
  • a configuração do conflict permite informar explicitamente sobre pacotes conflitantes …

e assim por diante.

Consciência de propriedade

Quando você precisa de um plugin do WPackagist, a parte “fornecedor” do nome do pacote é sempre o wpackagist-plugin .

Então, as pessoas vão exigir o seu plugin como:

 "require": { "wpackagist-plugin/your-plugin-name":"1.*", } 

Se você colocar o plugin no packagist, você pode usar seu próprio prefixo do fornecedor e acho melhor para o marketing:

 "require": { "your-name/your-plugin-name":"1.*", } 

Autoload

O compositor fornece carregamento automático para pacotes. Se você decidir usar o Composer, pode se beneficiar disso. No entanto, considerando que você está enviando o seu plug-in para o reimportação oficial, você deve levar em conta que a maioria do seu usuário provavelmente instalará seu plugin não usando o Composer. Isso significa que você tem que possibilidades:

  • envie a pasta “fornecedor” (que contém o autoload) insider sua pasta de plugins no repo oficial
  • faça uso de um carregador automático personalizado ou um mecanismo de carregamento manual caso o plugin seja usado sem compositor.

A segunda possibilidade é mencionada apenas porque o seu plug-in não tem dependencies tratadas pelo Composer, caso contrário, a pasta do fornecedor do navio é a única possibilidade de fazer o seu plug-in funcionar sem o Composer, mas não é livre de problemas: quando os plugins diferentes estão instalados com a pasta do fornecedor incorporado, existe. a possibilidade de conflitos de versão se diferentes plugins enviarem uma versão diferente do mesmo pacote.

Suporte ao compositor explícito

Ao adicionar composer.json você faz com que as pessoas saibam que você apoia explicitamente o Composer. Por exemplo, quando eu procuro um plugin, encontrar um composer.json na pasta do plugin é uma grande vantagem para mim, pois eu costumo não usar plugins que não fazem isso.

Além disso, existem ferramentas que visam o plugin explicitamente apoiando o Composer.

Por exemplo, eu tenho um script que impede atualizações automáticas para o plugin / temas que possuem um composer.json .

O arquivo composer.json normalmente contém informações adicionais que não estão disponíveis no arquivo readme.txt . Então, poderia simplesmente servir como um arquivo readme para as dependencies do seu plugin.

Uma vez que o Composer está na checkbox de ferramentas de muitos desenvolvedores, isso poderia ajudá-los a entender melhor como o seu plugin está aparafusado.

Por exemplo, os plugins .org abondonados, seria útil disponibilizar esse arquivo para alguém que desejasse garfê-lo, atualizá-lo e estendê-lo.

Se quisermos registrar nosso plugin no packagist.org , então, é claro, precisamos disso.