Magento 2 в качестве требования разработчика для расширений


8

При написании расширения, имеет ли смысл добавлять magento/project-community-editionв require-devраздел composer.json?

Идея заключается в том, что потребуется только composer installускорить полную установку Magento для разработки или CI.

Чтобы настроить базу данных, я бы добавил пост-установочный скрипт с bin/magento setup:install.

Для использования инструментов тестирования, вам нужно скопировать autoload-devи require-devразделы из magento/project-community-editionпотому что те , используются только из корня, а не от требований.

Один из недостатков, который я вижу, заключается в том, что вам нужно изменить требуемую версию для тестирования более чем на двух разных версиях (две, потому что вы можете указать диапазон и установить его один раз --prefer-lowest), но это относительно легко обойти.

Что-нибудь еще, что я должен рассмотреть?

Ответы:


4

Ответ зависит от того, что нужно вашему CI.

Для модульных тестов я в настоящее время изучаю подход, включающий в раздел require только фактические модули Magento, которые у меня есть в качестве прямой зависимости (что я в любом случае получаю почти все модули так, чтобы Magento разбирался):

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

Это хорошо работает для одного из моих расширений, смотрите Трэвис здесь, но столкнулся с интересной проблемой другого расширения, где Magento должен автоматически создать интерфейс для макета - подробности здесь.

Если вы смотрите не только на модульные тесты, я думаю, что имеет смысл иметь встроенную среду Magento, в которой вы устанавливаете расширение, а не запускать скрипт установки для среды Magento в каждой сборке.


1

Выглядит разумно 2 очка, чтобы иметь в виду:

  1. Установка через композитор занимает довольно много времени
  2. Когда у вас есть несколько модулей, довольно неудобно поддерживать / обрабатывать процедуру установки внутри CI с помощью сценариев, уникальных для каждого модуля. Когда вам нужно что-то изменить здесь, вам придется изменить все имеющиеся у вас расширения.

Одним из способов избежать этого может быть сохранение всего, что связано со сборкой CI, в отдельном репозитории и включение его в модули в качестве под-репозиториев.


Размещено от имени Петра Самойлова с сайта ForeWorks, поскольку он не в StackExchange. :)


1

Имеет смысл включать только те модули Magento, которые требуются вашему модулю:

  • Для всех, кто его устанавливает, понятно, от чего все это слишком широко.
  • Вы, вероятно, хотите в основном выполнить его модульное тестирование (и некоторые интеграционные тесты), поэтому он не нуждается в работающем интернет-магазине.
  • Функциональные тесты могут быть созданы в вашем основном хранилище интернет-магазина, так как там имеет больше смысла использовать внешний интерфейс, а также зависеть от всей платформы как взаимосвязанных вещей.

По сути, сам ваш модуль не зависит от редакции всего сообщества, он зависит только от его части, так что это то, что нужно указать. Таким образом, вы все еще можете проверить его, но также не забывайте, что это за зависимости.


0

Также не уверен в этом. Мой первый подход - установить magento2 из образа докера для запуска всех тестов.

Это даст вам возможность выполнить тестовую среду за довольно короткое время, но вы должны создать более специфичную для сборки конфигурацию, чем, я думаю, устанавливать все через composer.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.