Magento 2作为扩展的作曲者开发要求

编写扩展名时，将其添加magento/project-community-edition到require-devcomposer.json部分会有意义吗？

其背后的想法是，只需要composer install启动一个完整的Magento安装即可进行开发或CI。

要设置数据库，我将使用添加一个安装后脚本bin/magento setup:install。

要使用测试工具，您需要从中复制autoload-dev和require-dev部分，magento/project-community-edition因为它们仅从根目录使用，而不是从需求中使用。

我看到的一个缺点是，您必须更改所需的版本才能在两个以上的不同版本上进行测试（两个是因为您可以指定一个范围，然后使用进行安装--prefer-lowest），但这相对较容易解决。

我还有什么需要考虑的吗？

答案取决于您的CI需求是什么。

对于单元测试，我目前正在研究仅在require部分中包含我直接依赖的实际Magento模块的方法（无论如何，我通过这种方式获取几乎所有模块都是为了让Magento能够解决）：

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

这对于我的一个扩展来说效果很好，请在此处查看Travis，但在另一个扩展中却遇到了一个有趣的问题，Magento应该自动生成用于模拟的接口-详细信息。

如果您不打算进行单元测试，那么我认为有一个预先构建的Magento环境是很有意义的，您可以在其中安装扩展，而不是在每次构建时都为Magento环境运行安装脚本。

看起来很合理。请记住两点：

1. 通过composer安装需要花费一些时间
2. 当您有许多模块时，使用每个模块唯一的脚本来支持/处理CI中的安装过程是非常不舒服的。当您需要在此处进行更改时，必须更改所有扩展名。

避免这种情况的一种方法是，将与CI构建相关的所有内容都保存在单独的存储库中，并将其作为子存储库包含在模块中。

^{由于他不在StackExchange上，因此代表来自forenWorks的Peter Samoilov发布。:)}

仅包含模块所需的Magento模块是有意义的：

• 很明显，每个安装它的人都依赖它，整个社区版太广泛了。
• 您可能主要想对其进行单元测试（以及一些集成测试），因此它不需要运行的网上商店。
• 可以在您的主要webshop存储库中创建功能测试，因为在这里使用前端更有意义，并且还依赖于整个框架作为互连的事物。

基本上，您的模块本身并不依赖于整个社区版本，而仅依赖于它的一部分，因此可以指定。这样，您仍然可以测试它，但也要弄清它们之间的依赖关系。

也不确定这一点。我的第一种方法是从docker映像安装magento2来运行所有测试。

这将在很短的时间内为您提供一个正在运行的测试环境，但是与我认为通过composer安装所有内容相比，您必须创建一个更加特定于构建的配置。