Magento 2が拡張機能の作曲者の開発要件として

拡張機能を作成するとき、composer.json magento/project-community-editionのrequire-devセクションに追加することは理にかなっていますか？

その背後にある考え方はcomposer install、開発またはCIのために完全なMagentoインストールを起動するだけでよいということです。

データベースを設定するには、を使用してポストインストールスクリプトを追加しbin/magento setup:installます。

テストツールを使用するには、autoload-devおよびrequire-devセクションをコピーする必要がありmagento/project-community-editionます。これらは、要件からではなく、ルートからのみ使用されるためです。

私が目にする1つの欠点は、3つ以上の異なるバージョンでテストするために必要なバージョンを変更する必要があることです（2つは、範囲を指定してで一度にインストールできるためです--prefer-lowest）が、これは比較的簡単に回避できます。

他に検討する必要があることはありますか？

答えは、CIのニーズによって異なります。

単体テストの場合、私は直接的な依存関係として持っている実際のMagentoモジュールのみをrequireセクションに含めるためのアプローチを現在検討しています（この方法でMagentoが整理するために、ほぼすべてのモジュールを取得します）。

"require": {
  "magento/module-backend": "~100.0.2",
  "magento/module-sales": "~100.0.2"
}

これは私の拡張機能の1つでうまく機能します。ここでTravisを参照してください。ただし、Magentoがモックのインターフェースを自動生成する別の拡張機能で興味深い問題が発生しています-詳細はこちら。

単体テストの先を見据えている場合、ビルドごとにMagento環境のインストールスクリプトを実行するのではなく、拡張機能をインストールするビルド済みのMagento環境を用意することは理にかなっていると思います。

合理的に見えます。留意すべき2つのポイント：

1. composerによるインストールにはかなり時間がかかります
2. 多くのモジュールがある場合、各モジュールに固有のスクリプトを使用してCI内のインストール手順をサポート/処理するのは非常に不快です。ここで何かを変更する必要がある場合は、すべての拡張機能を変更する必要があります。

これを回避する方法の1つは、CIでのビルドに関連するすべてのものを別個のリポジトリーに保持し、サブリポジトリーとしてモジュールに含めることです。

^{StackExchangeを利用していないため、aheadWorksのPeter Samoilovの代理として投稿されました。:)}

モジュールに必要なMagentoモジュールのみを含めることは意味があります。

• 依存しているものをインストールしているすべての人にとって明らかです。コミュニティエディション全体は広すぎます。
• 主に単体テスト（および一部の統合テスト）を行う必要があるため、機能するWebショップは必要ありません。
• フロントエンドを使用する方が合理的であり、相互接続されたものとしてフレームワーク全体に依存しているため、機能テストはメインのWebショップリポジトリで作成できます。

基本的に、モジュール自体はコミュニティエディション全体に依存するのではなく、モジュールの一部にのみ依存するため、指定する必要があります。このようにしてテストすることもできますが、依存関係を明確にしておくこともできます。

これについてもわかりません。私の最初のアプローチは、すべてのテストを実行するためにDockerイメージからmagento2をインストールすることです。

これはかなり短い時間で実行中のテスト環境を提供しますが、私が考えるcomposer経由ですべてをインストールするよりもビルド固有の構成を作成する必要があります。