Как у вас организована одновременная разработка библиотеки и использующего ее приложения?

Question

[WindBridges]

У меня часто возникает ситуация, когда в процессе разработки какого-либо проекта, прямо в нем делается библиотека, которая по сути является отдельным независимым решением и могла бы использоваться в других проектах. Другими словами, хочется выпилить ее из основного проекта и положить в отдельный репозиторий, подтянув в проект как вендора. Но благодаря тому, что я до сих пор не нашел для себя удобного сценария для такой ситуации, многие свои библиотеки либо перемещались из проекта в проект с помощью простого копирования файлов, либо так и оставались там, воплощаясь в новых проектах другими реализациями.

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

Подходят ли вложенные репозитории для этой цели? В общем любые советы по теме приветствуются.

UPD: Я понял, как упростить вопрос. Как сохранить возможность вносить правки в библиотеку прямо в основном проекте без необходимости до определенного момента коммитить их в репозиторий?

Comments

[Дмитрий]

Ну так и делайте, пишем библиотеку, используем в разных проектах, по необходимости добавляем функционал

[WindBridges]

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

Answer 1

[BoShurik]

Вы можете подтягивать зависимости из директории:
https://getcomposer.org/doc/05-repositories.md#path
Единственное, после разработки этот параметр придется убрать, чтобы на проде зависимость подтягивалась из гита

Как вариант использовать preffered-install

"config": {
    "preferred-install": {
        "my/lib": "source"
    }
},

Т.о. в директории venodr/my/lib будет содержаться git репозиторий и можно будет делать коммиты прямо от туда.

Лично я остановился на костыльном варианте :) Просто делаю папку venodr/my/lib - симлинком на директорию, в которой лежит проект с этой либой. Что-то вроде первого вариант, но не надо будет подчищать за собой composer.json. В итоге получается так:

• веду разработку библиотеки в отдельной директории/проекте
  
• делаю симлинк директории в вендор и проверяю работу в приложениях
  
• если все ок, тегаю релиз
  
• удаляю симлинк (не обязательно, но тогда в проекте библиотеки git будет в статусе detached head, что не критично)
  
• делаю composer update
  

Comments

[WindBridges]

Спасибо, похоже, это то что нужно, обязательно посмотрю. А не разбирались, может в "preferred-install" есть какой-либо аналог разделения окружения, по типу require/require-dev? Тогда бы возможно не пришлось симлинк делать или composer.json постоянно править - в деве он бы ссылался на папку, а в продакшне на репозиторий, как обычно.

[BoShurik]

WindBridges, вроде бы нет.
В вашем случае можно создать кастомный composer-dev.json и использовать что-то вроде:
COMPOSER=composer-dev.json composer update
не уверен, что имеет смысл, т.к. придется держать их оба актуальными