Download the PHP package entelisteam/lbaf-rector without Composer
On this page you can find all versions of the php package entelisteam/lbaf-rector. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download entelisteam/lbaf-rector
More information about entelisteam/lbaf-rector
Files in entelisteam/lbaf-rector
Package lbaf-rector
Short Description Recursive search for rector rules among dependencies
License MIT
Informations about the package lbaf-rector
lbaf-rector
Рекурсивный сборщик Rector-миграций по дереву зависимостей для LBAF-based проектов.
Пакет собирает Rector-конфиг из миграций всех установленных Composer-пакетов, которые объявили свои миграции через extra.lbaf-rector-migrations, плюс миграции самого корневого проекта (если они есть). Это позволяет каждому пакету в экосистеме LBAF поставлять свои Rector-правила и быть уверенным, что они применятся в любом проекте, где этот пакет установлен.
Установка
Зависимость подключается в любой LBAF-based проект — даже если у самого проекта нет своих Rector-миграций. В этом случае пакет всё равно соберёт и применит миграции из всех зависимостей.
Настройка проекта
1. rector.php в корне проекта
Создайте rector.php со следующим содержимым:
По умолчанию миграции применяются к каталогу src/ корневого проекта.
2. Composer-скрипты
Добавьте в composer.json секцию scripts:
Использование:
Собственные Rector-миграции в проекте
Если проект реализует свои Rector-миграции, они должны удовлетворять следующим требованиям.
1. Класс-реестр миграций
Создайте класс, реализующий EntelisTeam\Lbaf\Rector\RectorMigrationListInterface. Метод all() должен вернуть список FQN классов-миграций:
2. Регистрация в composer.json
В composer.json добавьте ключ extra.lbaf-rector-migrations с полным именем класса-реестра:
3. Autoload
Namespace, в котором находятся класс-реестр и сами миграции, обязан быть в секции autoload (а не autoload-dev) — иначе при запуске Rector в зависимых проектах классы не будут найдены.
Рекомендация: для миграций используйте отдельный namespace второго уровня (например, Vendor\MyProject\Rector\) и отдельную папку, не пересекающуюся с src/:
Это нужно для того, чтобы миграции зависимостей случайно не «приехали» на код самих миграций проекта и не сломали их.
Требования к Rector-миграциям
Каждый класс-миграция, попадающий в MigrationList::all(), должен удовлетворять двум требованиям.
1. Сигнатура
Класс должен реализовывать статический метод apply, принимающий и возвращающий RectorConfigBuilder:
RectorMigrationManager последовательно прокидывает один и тот же RectorConfigBuilder через apply() каждой миграции, накапливая правила.
2. Нейминг
Миграции всех пакетов (зависимости + корневой проект) собираются в один плоский список и сортируются по basename класса (без namespace). Из этого следуют два правила:
- Уникальный basename в пределах всей экосистемы. Два класса
AddStrictTypesиз разных пакетов столкнутся в сортировке непредсказуемо. Закладывайте уникальность в само имя класса, а не только в namespace. - Префикс со словом Migration и датой-временем в формате
YYYYMMDD_HHMM— рекомендуемый способ получить стабильный, воспроизводимый порядок применения:
Дата-время отражает момент создания миграции; более ранние применяются раньше. Такая схема одновременно решает проблему уникальности (дата + описание) и порядка.
Кастомные пути применения
По умолчанию миграции применяются к src/ корневого проекта. При необходимости в RectorMigrationManager::apply() можно передать массив путей относительно корня проекта — например, чтобы применить миграции и к тестам: