У меня есть приложение A, у которого есть файл composer.json, определяющий зависимость от пакета P, который является моим собственным новым блестящим пакетом. В моем пакете P есть файл composer.json, который определяет зависимости от библиотеки L и рамки F. В моем пакете P пока нет удаленного репозитория, и он еще не опубликован на packagist.org – я в основном занимаюсь этим, пробуя разные вещи запустив приложение A в браузере и постоянно изменяя свой пакет P, от которого зависит приложение A.
Есть некоторые проблемы, которые действительно усложняют рабочий процесс для меня:
1) Определение зависимости от A на P возможно только с помощью локального репозитория, как описано здесь: https://getcomposer.org/doc/05-repositories.md Проблема заключается в том, что это заставляет меня совершать каждое изменение P до Я могу проверить его на A.
2) Ссылаясь на 1) это означает, что я должен запускать composer update каждый раз, когда я совершил изменение на P. (Которое я не хочу совершать в первую очередь.)
3) С другой стороны, когда я не использую локальный репозиторий в P, я не могу определить реальную зависимость от A на P, что означает, что запущенная composer install не будет устанавливать зависимости L и F, определенные в файле composer.json из P ,
Итак, в моем решении есть два возможных рабочих процесса:
1) Зафиксируйте изменения в composer update P, composer update в A и посмотрите, как это изменилось.
2) Не используйте локальные репозитории в качестве зависимостей и просто скопируйте зависимости, определенные в файле composer.json P, в файл composer.json файла A, чтобы иметь возможность использовать composer install для получения зависимостей L и F.
В основном я ищу рабочий процесс для разработки нового пакета композиторов, где я могу запустить composer install/update для установки всех зависимостей сторонних разработчиков, но без необходимости вносить изменения в свои локальные пакеты для проверки изменений.
Есть ли какое-либо решение упомянутых проблем?
Большое спасибо!
Решение, которое я использую, когда я в ситуации, когда мне нужно работать с несколькими пакетами в одно и то же время, заключается в регистрации каждого пакета локально, после composer install или после первого composer update я удаляю этот пакет из каталога поставщика и ссылаюсь на него где я храню локальную версию «WIP».
Например:
my_vendor/packageA , который зарегистрирован локально внутри ~/.composer/config.json . composer update my_vendor/packageA чтобы сделать композитор осведомленным о моем новом пакете. Который оставит меня с чем-то вроде:
Это позволяет мне:
packageA даже изнутри моего поставщика packageA прежде чем я смогу использовать эти изменения внутри моего projectA . Когда packageA будет достаточно стабильным, символическая ссылка будет удалена, и все вернется к нормальной работе, используя версию VCS / packagist.
Я пробовал разные решения с течением времени, и я обнаружил, что это работает лучше всего для меня.
Альтернативным решением, которое я использую, когда могу, является регистрация каталогов PSR-0 вручную, для каждого префикса:
<?php $autoloader = require_once __DIR__.'/vendor/autoload.php'; $autoloader->add('MyVendor\\Dummy\\', '/path/to/dummy-component/src'); // now you can use MyVendor\Dummy as normal.
Примечание. Для PSR-4 существует метод addPsr4() .