web-dev-qa-db-ja.com

自分のプラグインにcomposer.jsonファイルを含むのはなぜですか？

私のプラグインの潜在的なユーザーがすでにWPackagistを介してパッケージとして入手できる場合、自分のプラグインにcomposer.jsonファイルを明示的に含めることの利点は何ですか？

phpcomposer
7
henrywright

TL、DR

Composerをサポートしたい場合は、composer.jsonを追加することをお勧めします。WPackagistにパッケージを作成させてください。

いくつかの理由があります、誰も本当に重要ではありませんが、composer.jsonを作成するのに多くの努力を必要としないことを考えると、おそらくそれは価値があります。

composer.jsonの利点

composer.jsonを使用する利点の完全なリストは以下のとおりです。

開発者向け

あなたがパッケージを必要とするとき、Composerはrepositoriesを調べてその特定のパッケージを見つけます。 PackagistとWPackagistは2つのリポジトリです。

違いは、Packagistは常にComposerによって解析されるのに対し、WPackagistは手動でプロジェクトcomposer.jsonに追加する必要があるということです。

Packagistでプラグインを要求するには、composer.jsonに1行必要です。

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

WPackagistでプラグインを要求するには、リポジトリも設定する必要があります。

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

これはコマンドラインを使うときにも関係します。

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

VS

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

パフォーマンス

プロジェクトにさらにリポジトリが含まれている場合、Composerは すべてのリポジトリ に対してpingを実行してパッケージに関する情報を検索します。

だからWPackagistリポジトリを追加するとインストールが遅くなる。また、すべてのサーバーが停止しても問題ないことを考慮してください。それはWPackagistの背後にあるものよりもはるかに大きい企業に起こるので、あなたが追加するすべてのリポジトリは、それが失敗のさらなる可能なポイントです。

設定

composer.jsonを持つことの利点の1つは、Composerがプラグインを取得する方法を設定できることです。

たとえば、WPackagistにパッケージ名を自動的に作成させる代わりに、 name プロパティでパッケージ名を設定することができます。

さらにcomposer.jsonでできる設定はたくさんありますが、ほんの数例です。

  • 開発版のプラグインの互換性を向上させるために branch-alias 設定を使うことができます
  • 依存関係がない場合でも、 require 設定を使用して最小のPHPバージョンを設定できます。
  • conflict 設定は競合するパッケージについて明示的に知らせることを可能にします...

等々。

所有権の認識

WPackagistからのプラグインが必要な場合、パッケージ名の「ベンダ」部分は常にwpackagist-pluginです。

だから人々はあなたのようなプラグインが必要になります：

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

あなたがpackagistにプラグインを置けば、あなたはあなた自身のベンダー接頭辞を使うことができます、そして私はマーケティングのためにもっと良いと思います：

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

オートロード

Composerはパッケージに自動ロードを提供します。 Composerを使用することにした場合は、それを利用できます。ただし、プラグインを公式リポジトリに出荷することを考えると、ユーザーの大多数がおそらくComposerを使用せずにプラグインをインストールすることを考慮する必要があります。それはあなたが可能性を持っているということです。

  • 公式リポジトリのあなたのプラグインフォルダの中に "autolad"を含む "vendor"フォルダを送ってください
  • プラグインがComposerなしで使用される場合は、カスタムオートローダまたは手動ロードメカニズムを使用してください。

二つ目の可能性は、あなたのプラグインがComposerによって扱われる依存関係を持っていないという理由だけで言及されています。異なるプラグインが同じパッケージの異なるバージョンを出荷する場合、バージョンが衝突する可能性があります。

明示的Composerのサポート

composer.jsonを追加することで、Composerを明示的にサポートしていることを人々に知らせます。例えば、私がプラグインを検索するとき、私はそれをしないプラグインを使用しない傾向があるので、プラグインフォルダーでcomposer.jsonを見つけることは私にとって大きなプラスです。

さらに、Composerを明確にサポートするプラグインをターゲットとするツールもあります。

例えば、私はcomposer.jsonを持つプラグイン/テーマの自動更新を防ぐスクリプトを持っています。

8
gmazzap

composer.jsonファイルには通常、readme.txtファイルでは利用できない追加情報が含まれています。それでそれはあなたのプラグインの依存関係のための readme ファイルとして単に役立つことができます。

Composer は多くの開発者のツールボックスに入っているので、プラグインがどのように結び付けられているかを理解するのに役立ちます。

例えば.orgプラグインを廃止したので、そのファイルをフォークし、更新し、そして拡張したい人のためにそのファイルを利用可能にするのは便利でしょう。

プラグインを packagist.org に登録したい場合は、もちろん必要です。

1
birgire