Редактирование нескольких пакетов PHP, которые управляются в композиторе

Я использую композитор для управления своими зависимостями. Эти зависимости расположены в репозитории packagist (общедоступном) и в локальном репозитории композиторов моей компании, который сам получает свои пакеты из экземпляра компании gitlab, где на сервер пакетов отправляются только теги.

Теперь к моей проблеме.

У меня есть пакет, который я назову А. Пакет A имеет зависимость от B. Я редактирую код в B, который я помещаю в ветку git, которая по характеру установки находится только на gitlab, а не на сервере пакетов. B имеет зависимость от C.

Я также должен редактировать личную библиотеку D. D является зависимостью C.

Поэтому я редактирую код в B и D. Мне нужно изменить путь автозагрузки классов psr-4 в D и добавить новое пространство имен в D.

т.е. До:

"autoload": {
  "psr-4": {
     "hello\\hi": "src/"
  }
}

После:

"autoload": {
  "psr-4": {
     "hello\\hi\\": "src/abc",
     "foor\\bar\\": "src/def",
  }
}

Как мне заставить автозагрузчик подбирать новые классы, когда для версии D установлен тег (например, ^ 2.0) в C.

Обычно мне требуется версия D для разработчиков в A. Но композитор утверждает, что для пакета C требуется пакет D в версии ^ 2.0.

Мой текущий обходной путь кажется неуклюжим: Я изменил версию D в C на dev-<branch in gitlab of D> Я отправил новую ветку в gitlab C. В B я изменил версию C на dev-<branch in gitlab of C>. Я отправил новую ветку в gitlab B. А в a я определяю версию B как dev-<branch in gitlab of B>.

Но ветки gitlab не будут обнаружены, поэтому мне пришлось добавить репозитории gitlab в раздел репозиториев A.

Это должно быть проще, например, принудительно установить пакет независимо от других зависимостей. Это только для целей разработки и тестирования, а не для производства.

Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Оживление вашего приложения Laravel: Понимание режима обслуживания
Оживление вашего приложения Laravel: Понимание режима обслуживания
Здравствуйте, разработчики! В сегодняшней статье мы рассмотрим важный аспект управления приложениями, который часто упускается из виду в суете...
Установка и настройка Nginx и PHP на Ubuntu-сервере
Установка и настройка Nginx и PHP на Ubuntu-сервере
В этот раз я сделаю руководство по установке и настройке nginx и php на Ubuntu OS.
Коллекции в Laravel более простым способом
Коллекции в Laravel более простым способом
Привет, читатели, сегодня мы узнаем о коллекциях. В Laravel коллекции - это способ манипулировать массивами и играть с массивами данных. Благодаря...
Как установить PHP на Mac
Как установить PHP на Mac
PHP - это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать...
1
0
118
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Во-первых, тот факт, что вы это делаете, предполагает проблему с вашей архитектурой. Общая библиотека должна иметь четко определенную цель и четко определенный API, который можно тестировать независимо. Таким образом, изменения в пакете D должны быть определены как изменения в этом API и проверены на соответствие этому определению. Возможно, вы захотите провести интеграционное тестирование с его непосредственными зависимостями, но работа с цепочкой из 4 библиотек — плохой знак.

Тем не менее, это реальный мир, так что это, вероятно, не то, что вы можете исправить за ночь.

Псевдоним версии в composer.json позволяет указать, каким ограничениям версии соответствует версия (например, ветка разработки). Это можно указать одним из двух способов (вам не нужны оба):

  • В ветке dev репозитория D можно указать {"extra":{"branch-alias":{"dev-foo": "2.0.x-dev"}}}.
  • В ветке dev репозитория A можно указать {"require":{"package/D": "dev-foo as 2.0.x-dev"}}

В качестве альтернативы, если вы активно разрабатываете обе ветки, а не просто проводите интеграционное тестирование библиотеки, вы можете вообще обойти Composer. Если вы установите для вариант preferred-install значение source, а затем composer install, каждая библиотека будет полным клоном git, и вы сможете переключать ветки и редактировать напрямую. Вы можете использовать composer status, чтобы отслеживать, что вы редактировали вручную. Если вы в конечном итоге сделаете это, определенно стоит подумать о том, как избежать необходимости в этом в будущем.

Да, я согласен на 100%, что в этой архитектуре есть серьезная проблема. К сожалению, я не могу изменить его в данный момент. Он был построен задолго до того, как я начал с ним работать, и времени и денег на его очистку не хватает. Я попробую ваше предложение и сообщу как можно скорее. заранее спасибо

PrinzJuliano 30.07.2019 08:33

Спасибо за помощь. Второе предложение работало отлично без каких-либо проблем. Это элегантное решение, которое я искал.

PrinzJuliano 30.07.2019 08:41

Другие вопросы по теме