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

Question

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

У меня есть приложение 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) Зафиксируйте изменения в P, composer update в А и посмотреть, как сработало изменение.

2) Не используйте локальные репозитории как зависимости и просто копия зависимости, определенные в файле composer.json P для файла composer.json A, чтобы иметь возможность использовать composer install чтобы получить зависимости L и F.

В основном я ищу рабочий процесс для разработки нового пакета композитора, где я могу запустить composer install/update установить все сторонние зависимости, но без необходимости фиксировать изменения в моих собственных локальных пакетах для проверки изменений.

Есть ли какое-либо решение упомянутых проблем вообще?

Большое спасибо!

0

composer-php dependency-management package-development php workflow

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Решение, которое я использую, когда мне нужно работать с несколькими пакетами одновременно, заключается в регистрации каждого пакета локально и после composer install или после первого composer update Я удаляю этот пакет из каталога вендора и помещаю его в ссылку, где храню локальную версию «WIP».

Например:

В composer.json мне требуется my_vendor/packageA, который зарегистрирован локально внутри ~/.composer/config.json,
Я исполняю composer update my_vendor/packageA чтобы композитор узнал о моем новом пакете.
После того, как композитор закончит установку моего пакета:
- cd vendor / my_vendor && rm -rf packageA && ln -s ../../../packageA.

Что оставит меня с чем-то вроде:

working_dir /
- packageA / (здесь я работаю над packageA)
- Projecta /
  - приложение
  - ЦСИ
  - продавец /
    - Vendor1 /
    - vendor2 /
    - my_vendor /
      - packageA -> ../../../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() метод.

2