知っておく必要がある Composer バージョンの制約

コンポーザーをまだ知らない場合は、コンポーザーの使用方法のチュートリアル##を参照してください。 #コラムを読んで読み始めてください。

私は、多くの人が、使用するコンポーザー パッケージ間の依存関係の制約に苦労しているのを見てきました。この記事がいくつかの問題の原因を指摘し、それらを回避する方法を提供することを願っています。最悪のシナリオから始めて、制約を段階的に改善していきます。

全能のアスタリスク:

#Composer には依存関係パーサーがあるので、必要なものを自動的に見つけてくれますよね。間違っている。

* を使用してバージョン制約を宣言することは、おそらく最悪のプラクティスの 1 つです。なぜなら、自分が何を得るかを完全にコントロールできないからです。 minimum-stability およびその他の制約に一致する任意のバージョンにすることができます。

あなたは基本的に Composer とロシアン ルーレット ゲームをプレイしていることになりますが、最終的には害を及ぼすことになります。そうなると、あなたを失望させたのはツールのせいかもしれません。

引き続き不注意な場合は、少なくとも

dev-master というラベルが付いている最新の開発バージョンを信頼してください。

ハードコードされたブランチ名

つまり、現在

dev-master を使用していることになります。問題は、dev-master が指すコードが変更される可能性があることです。少なくとも、得られるものは常に不安定なパッケージです (composer によって表される安定性フラグによれば不安定です)。ただし、より大きな問題は、dev-master の意味がいつでも変更される可能性があることです。

たとえば、これは最新の 1.0 開発バージョンを表します。開発者がバージョン 1.1 の開発を開始すると言うと、ブランチ名

dev-master は 1.0 ブランチを指すのではなく、最新の 1.1 開発ブランチを指すようになります。

このライブラリの開発を綿密にフォローしない限り、

composer update コマンドを実行するまで問題が発生し、一日が台無しになってしまうでしょう。したがって、ブランチ名を直接参照することは持続可能な解決策ではありません。幸いなことに、エイリアスに関しては composer が役に立ちます。

ブランチ エイリアス

ブランチ エイリアスは、パッケージ管理者が

composer.json に入力できる属性で、これらのブランチ名をバージョンにマッピングできるようにします。 。

1.0、2.1 などのブランチ名は必要ありません。

Composer はこれらをすでに処理しています。

ただし、

master のようなブランチ名は、dev-master という名前のバージョンを生成するため、これにエイリアスを付ける必要があります。 Composer ドキュメントにはエイリアスに関する優れた記事があり、ブランチ エイリアスを定義する方法を説明しています。

{
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }
}

dev-master バージョンは にマップされます。 1.0.x-dev 、

のエイリアスでは、これは基本的に、

1.0.*@dev 制約を持つパッケージを要求できることを意味します。この利点は、1.0 の意味が定義され、変更されないことです。また、安定版リリースへの切り替えも容易になります。

ブランチ エイリアスの警告には、パッケージ管理者が警告を追加する必要があります。ブランチ エイリアスのないライブラリを使用している場合は、上記の

extra セクションを combos.json に追加してプル リクエストを送信します。

安定バージョン

1.0.*@dev この制約はすでに非常に優れています。しかし問題は、今のところ安定したバージョンがまだ存在しないことです。まだ不安定なバージョンを実行しているという事実以外、コードには何も問題はありません。

ただし、他の人のプロジェクトがあなたのパッケージに依存している場合、ユーザーは明示的に @dev フラグを使用して Composer が不安定なバージョンをインストールできるようにするか、単にプロジェクトの minimum-stability Level を下げる必要があります。 、つまり、すべての依存パッケージの不安定なバージョンが入手されることになります。

開発バージョンの不安定性を回避する最善の方法は、開発バージョンにリリース タグを付けることです (安定バージョンのリリースを指します)。 release のタグが付いていないライブラリを使用している場合は、タグが付けられるまでメンテナに警告してください。今やれ！

Composer コミュニティのメンバーとして、私たちは責任を負わなければなりません。安定したバージョンをリリースし、CHANGELOG (変更ログ) を維持する必要があります。それは簡単ではありませんが、エコシステム全体に大きな変化をもたらすでしょう。真実かつ意味的に物事にラベルを付けることを忘れないでください。

安定バージョンをリリースするときは、 @dev 識別子を削除し、制約を 1.0.* に変更できます。

次のメジャー バージョン

依存するパッケージのすべてのリリース ノードがセマンティック バージョニングのルールに準拠し、厳密に下位互換性がある場合は、段階的に制約を増やす。

現在 1.0.* バージョンには潜在的な互換性の問題があり、 1.1 バージョンが間もなくリリースされます。制約が 1.0 であるが、他の人が 1.1 バージョンの新機能を必要とする場合 (下位互換性を覚えていますか?)、その人は 1.1 バージョンをインストールできません。 。したがって、制約を 1.* のように書き直す必要があります。

すばらしいですね。 1.1 バージョンの新機能に依存しない限り、制約を変更する必要はなく、引き続き 1.0 このバージョンと一致します。新しい機能はありません。

次に、制約を >=1.1, に変更しますが、この書き方はさらに面倒です。チルダ演算子を使用すると、上記の式を <code> ~1.1 のように簡潔に表現できます。これは、1.1 より上のすべての 1.* バージョンを意味します。これで、セマンティック バージョンではチルダ演算子を使用し、パッケージの互換性を最大化することが推奨されることがわかりました。

TLDR

ブランチエイリアス を使用します。

発行の信頼性とセマンティックを高めるために、発行にラベルを付けます。

~ 演算子を使用します。

以上が知っておく必要がある Composer バージョンの制約の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。