web-dev-qa-db-fra.com

Pourquoi inclure un fichier composer.json avec mon plugin?

Quel est l’avantage d’inclure explicitement un fichier composer.json dans mon plugin si les utilisateurs potentiels de mon plugin peuvent déjà l’obtenir sous forme de paquet via WPackagist?

phpcomposer
7
henrywright

TL; DR

Si vous souhaitez prendre en charge Composer, ajouter un composer.json est préférable, laissez-le simplement à WPackagist créer un package pour vous.

Il y a plusieurs raisons, personne n'est vraiment important, mais étant donné que créer un composer.json ne demande pas beaucoup d'effort, cela en vaut probablement la peine.

composer.json Avantages

Ci-dessous une liste non exhaustive des avantages de l'utilisation de composer.json.

Développeur convivial

Lorsque vous avez besoin d'un package, Composer consulte référentiels pour trouver ce package spécifique. Packagist et WPackagist sont deux référentiels.

La différence est que Packagist est toujours analysé par Composer, alors que WPackagist doit être ajouté manuellement au projet composer.json.

Pour requérir un plugin sur Packagist, vous avez besoin d'une seule ligne dans composer.json:

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

Pour exiger un plugin sur WPackagist, vous devez également configurer les référentiels:

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

Ceci est également pertinent lorsque vous utilisez la ligne de commande, voir

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

CONTRE

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

Performance

Lorsqu'un projet contient plusieurs référentiels, Composer interroge tous pour rechercher des informations sur les packages.

Ainsi, l'ajout du référentiel WPackagist ralentit l'installation. Considérez également que tous les serveurs peuvent être en panne, quelle que soit la résonance. Cela arrive à des entreprises beaucoup plus grandes que celle derrière WPackagist, donc chaque référentiel ajouté, c'est un point de défaillance supplémentaire possible.

Configuration

L'un des avantages d'avoir un composer.json est que vous pouvez configurer la manière dont Composer va chercher votre plugin.

Par exemple, vous pouvez utiliser configurer le nom du package dans la propriété name , au lieu de laisser WPackagist créer le nom du package à votre place.

De plus, il y a beaucoup de configuration qui peut être faite dans composer.json, juste quelques exemples:

  • vous pouvez utiliser le paramètre branch-alias pour améliorer la compatibilité de la version de développement du plugin
  • même si vous ne possédez aucune dépendance, vous pouvez utiliser le paramètre require pour définir une version minimale de PHP,
  • le paramètre conflict vous permet de vous informer de manière explicite sur les paquets en conflit ...

etc.

Prise de conscience de la propriété

Lorsque vous avez besoin d’un plugin de WPackagist, la partie "fournisseur" du nom du paquet est toujours wpackagist-plugin.

Donc, les gens auront besoin de votre plugin comme

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

Si vous mettez le plugin sur packagist, vous pouvez utiliser votre propre préfixe de fournisseur, et je pense que c'est mieux pour le marketing:

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

Chargement automatique

Composer fournit un chargement automatique des packages. Si vous décidez d'utiliser Composer, vous pouvez en bénéficier. Cependant, étant donné que vous envoyez votre plug-in au référentiel officiel, vous devez prendre en compte le fait que la majorité de vos utilisateurs installera probablement votre plug-in sans utiliser Composer. Cela signifie que vous avez des possibilités:

  • expédier le dossier "vendor" (qui contient le chargement automatique) dans le dossier de votre plugin dans le dépôt officiel
  • utilisez un autochargeur personnalisé ou un mécanisme de chargement manuel dans le cas où le plugin est utilisé sans Composer.

La deuxième possibilité est mentionnée uniquement parce que votre plug-in n'a pas de dépendances gérées par Composer. Sinon, le dossier du fournisseur Ship est la seule possibilité de faire fonctionner votre plug-in sans Composer, mais il n'est pas sans problème. la possibilité de conflits de version si différents plugins livrent une version différente du même paquet.

Prise en charge du compositeur explicite

En ajoutant composer.json, vous faites savoir que vous soutenez explicitement Composer. Par exemple, quand je cherche un plugin, trouver un composer.json dans le dossier des plugins est un gros plus pour moi, car j'ai tendance à ne pas utiliser de plugins qui ne le font pas.

De plus, il existe des outils qui ciblent explicitement le plug-in prenant en charge Composer.

Par exemple, j'ai un script qui empêche les mises à jour automatiques pour les plugins/thèmes qui ont un composer.json.

8
gmazzap

Le fichier composer.json contient généralement des informations supplémentaires qui ne sont pas disponibles dans le fichier readme.txt. Donc, il pourrait simplement servir de fichier readme pour les dépendances de votre plugin.

Puisque Composer est dans la boîte à outils de nombreux développeurs, cela pourrait les aider à mieux comprendre comment votre plugin est assemblé.

Par exemple Pour les plugins .org abondonés, il serait pratique d’avoir ce fichier à la disposition de quelqu'un qui voudrait l’archiver, le mettre à jour et le prolonger.

Si nous voulons enregistrer notre plugin sur packagist.org , nous en aurons bien sûr besoin.

1
birgire