Являетесь вы разработчиком пакетов на PHP или нет, продолжайте читать. Я буду говорить о git-субмодулях простыми словами. Модульность — важная штука.
В чем проблема?
Давайте начнем разработку нашего пакета. Скорее всего вы не захотите публиковать свой пакет с самого начала, и вместо этого вы будете работать локально. На этом раннем этапе все идет хорошо.
Потом приходит время, когда вы решаете, что пора показать свой труд общественности. Вы изменяете неймспейсы и публикуете пакет на Packagist. Наверное, вы также создадите какой-нибудь демо-репозиторий, чтобы тестировать, что пакет работает должным образом на фреймворке.
Файловая структура становится примерно такой:
demo_project
.idea
.git
src \App
vendor
username-library
.git
src \Username\Library
...
Готово!?
Нет. Далеко не готово. Как вы видите, composer думает, что файлы из /vendor
можно трогать и радостно съедает ваш тяжкий труд при выполнении либо composer install
, либо composer update
. Вы можете сказать: «Не забывай сделать бэкап, прежде чем запускать обновление, придурок!». Но я не соглашусь. Физическая память дешевая, в то время как человеческая сильно ограничена.
Есть решение?
Да, есть такое. Оно сводится к двум шагам:
- Создать субмодуль
- Настроить автозагрузку
Субмодуль Git
С GitKraken создание субмодулей становится супер-простым. Просто скопируйте вашу библиотеку в демо-проект, таким образом, чтобы файловая структура выглядела так:
demo_project
.idea
.git
src \App
username-library \Username\Library
.git
src
...
GitKraken немедленно обнаружит новый субмодуль и предложит индексировать его также, как это происходит с файлами.
После этого новый субмодуль появится в разделе submodule в левом меню. Я не хочу больше говорить про субмодули, они интуитивно понятны, и у вас безусловно должно появиться полное понимание с течением времени.
Автозагрузка
В demo_project/composer.json
-> autoload
-> psr-4
вставьте такую строку:
"Username\\Library\\": "username-library/src/"
Это даст автозагрузчику знать, где искать классы вашей библиотеки. Кстати, теперь вам не надо держать вашу библиотеку в require
или require-dev
.
Рабочий процесс
Скорее всего вам захочется открывать demo_project
в вашей IDE, затем вносить правки в пакет. Таким образом вы получаете автодополнение и другую помощь от IDE.
Если вы используете CI (continuous integration), у меня есть для вас хорошие новости: поддержка субмодулей классная. А это значит, что вы можете без лишнего шума при push-е demo_project
делать автоматический деплой на демо-сервер. А при push-е вашей библиотеки — запускать тесты на различных версиях фреймворка.
В случае, если вы не знаете никакой CI-сервис, я советую Buddy Works.
Когда вы решите обновить зависимости, composer обновит папку vendor
как обычно, и ничего плохого не случится. Вам уже не надо ничего держать в голове, и проект аккуратно организован.
На этом все. Надеюсь мой подход сделает вас хоть немного продуктивнее.
Статью перевел aziev. Оригинал на Medium.com доступен по ссылке.