Введение

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

Подобный вопрос уже задан и ответил здесь, хотя я не думаю, что это полностью отвечает на вопрос.

Сводка

Я работаю с командой разработчиков по проекту. Мы используем фреймворк (для аргументации - структура не имеет значения), за исключением одного из требований, заключающегося в том, что мы используем composer.

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

Эти пакеты имеют свой собственный git репозитория и во время разработки приложения имеют отраслевые псевдонимы, установленные на dev-master.

Проблема №1

Чтобы приложение работало с моими пакетами, мне нужно зарегистрировать их с помощью composer.json, и это нормально, пока я не буду выполнять существующую работу по разработке моего пакета в своем репозитории, прежде чем я смогу запустить composer update.

Проблема № 2

Я выполнил начальную архитектуру пакета и composer.json. Я запускаю composer update, который завершается, и мой пакет доступен для приложения. Тем не менее, я продолжаю развивать этот пакет, в то время как другой разработчик уже совершил другое изменение этого пакета - то есть исправление ошибки.

Мне нужно обновить другой пакет, чтобы моя работа продолжалась, но я не могу, потому что это сделало бы предупреждение, похожее на:

Loading composer repositories with package information
Updating dependencies (including require-dev)         
  - Removing hu/admin (dev-master)
  The package has modified files:
  M composer.json
  M src/...
  Discard changes [y,n,v,?]?

Если я отвечу y, мои изменения сбрасываются и теряются навсегда. Если я выберу n, композитор будет прерван и мой проект будет разбит из-за того, что пакет не обновляется параллельно моим изменениям.

Проблема № 3

Еще одна проблема с этим способом разработки заключается в том, что если я работаю над своим пакетом за пределами vendor, и я совершаю свои изменения, я могу запустить composer update, но мое приложение не работает из-за фатальной ошибки. Я исправляю недостающую ; или другую небольшую синтаксическую ошибку. Я фиксирую это изменение и запускаю composer update - но я не хочу, чтобы моя история git была заполнена небольшими исправлениями и исправлениями синтаксического анализа только потому, что я не могу работать над своим пакетом в приложении параллельно с другими разработчиками/разработчиками приложение и другие пакеты или этот пакет.

Проблема № 4

Я обнаружил пакет на GuitHub под названием franzliedke/studio, который, похоже, частично решает мою проблему. После того, как пакет был опубликован из-за того, что он является полным/функциональным, он не может оставаться внутри каталога vendor/bin, невзирая на то, что исходные проблемы снова встанут.

Заключение

Мне интересно, как лучше всего обойти эту или любую лучшую практику для работы с пакетами с командами разработчиков без необходимости делать все это каждый раз, прежде чем я запустим composer update.

laravel имел функцию workbench что было довольно круто. Но был удален из версии 5.0 и так была плохая практика?

Ответ 1

Это то, что мы делаем в огромных проектах, состоящих из нескольких небольших композиционных компонентов, которые разрабатываются в одно и то же время:

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

/Application
-composer.json (Application json)
-/src
--/Component1
----composer.json (Component json)
--/Component2
----composer.json (Component json)
--/ApplicationFeature
----Class1.php
----Class2.php

Все приложение разработано в одном репозитории git, который устранит большинство ваших вышеупомянутых проблем. Затем время от времени разбивайте репозиторий приложений на однокомпонентные репозитории с помощью git subtree. Я написал небольшой php cli script, который разбивает проект на более мелкие компоненты и подталкивает их к соответствующим репозиториям компонентов. Существует множество преимуществ по сравнению с подмодулями git. Вся история фиксации компонента сохраняется и помещается в репозиторий компонентов. Дополнительная информация о поддеревках здесь Если вы заинтересованы, сообщите мне, я рад поделиться script, который разбивает/теги и, наконец, подталкивает отдельные компоненты, просто определяя отображение directory <-> componentName как json.