Как структурировать среду Silverstripe для разработки и тестирования модулей?

Question

Я просмотрел несколько постов в блоге на silverstripe.org, и все они приводят к видео / учебным пособиям по разработке модулей, которых больше не существует, потому что Silverstripe переделал весь их раздел «Уроки», который теперь фокусируется на том, как изменить весь сайт Silverstripe для удовлетворить ваши потребности.

Я пытаюсь найти и понять, каков рабочий процесс для разработки модулей? В основном, как мне структурировать экземпляр Silverstripe для разработки и тестирования модуля? На 4.x и 3.x?

Репозитории модулей содержат код ядра и все ресурсы, необходимые для модуля и только модуля, а также composer.json, в котором перечислены библиотеки и модули, от которых, конечно, зависит модуль. Проблема в том, что если я клонирую репозиторий и запускаю composer install, он установит все это, но я не получу загрузочный код Silverstripe, который поставляется вместе с установщиком - таким образом, я не могу протестировать свой модуль следующим образом.

Мой инстинкт подсказывает мне, что я должен разработать код моего модуля в папке mysite (3.x) или app (4.x) работающего экземпляра Silverstripe (т.е. composer create-project silverstripe/silverstripe-installer ./project-dir), но затем я ' Я обеспокоен отслеживанием зависимостей - в этой точке зрения модули и библиотеки, которые мне нужны для разработки, отслеживаются в ./project-dir/composer.json, а не в ./project-dir/<mysite or app>/composer.json. Копирование моих зависимостей вручную в каждую composer.json и обратно просто кажется подверженным ошибкам и противоречивым. И если я попытаюсь запустить composer install внутри app или mysite, то я получу каталог vendor внутри этой папки, который не используется, поскольку каталог сайта уже используется каталогом vendor уровень вверх.

Answer 1

Вместо того, чтобы существовал какой-то "мастер создания модулей", неизбежно придется заниматься какой-то ручной работой.

Что бы я обычно делал (для SilverStripe 4), чтобы создать папку mymodule в корневом проекте и начать в ней разработку.

Следующим шагом будет создание хранилища и определение файла composer.json с некоторыми основными требованиями (например, silverstripe / framework). Затем вы можете зафиксировать и отправить это, а затем включить его в проект SilverStripe 4 с помощью Composer (либо через конфигурацию хранилища VCS, либо через Packagist).

Отсюда, по крайней мере, есть место, где живет ваш код. Если вы настроили новый модуль как "type": "silverstripe-vendormodule", он будет установлен в vendor/yourname/yourmodule. Вы можете изменить код здесь при необходимости.

Вы также можете определить тип как "type": "silverstripe-module", и он будет установлен в корне проекта. Большинство модулей идут по пути продавца в SilverStripe 4, поэтому желательно следовать этому примеру.

В SilverStripe 3 вы можете сделать то же самое, что и это, но поскольку установщик Composer для модулей SilverStripe 3 по умолчанию помещает их в корневой каталог проекта, вы можете создать произвольные имена папок, например mymodule, в своем корневом проекте и сразу же приступить к разработке. в них.

Манифесты SilverStripe будут читать любую папку, в которой нет файла _manifest-exclude, и в которой есть либо файл _config.php, либо папка _config, так что легко приступить к работе и вы всегда можете преобразовать в любой момент эту папку в свой собственный модуль удалите, затем включите снова с требованиями Composer. Вы можете сделать это и в SilverStripe 4.