Короткий ответ на вопрос "по другому невозможно"?
Illuminate\Database\Capsule\Manager:
calls:
- [addConnection, ['%mysqlConnection%']]Если мы делаем разные модули в рамках монолита как подключать свои собственные сервисы не изменяя файл который правит коллега?
И параметр получить $this->config? или они здесь только, кхм, "внедряются"?
он не с потолка вопросы берет, а спрашивает то, что применяется на практике у них.
Мне кажется, если спросить про гика, исполнителя и головолома, работодатель напряжется) Я бы напряглась
Не нужен вам бандл, app - это и есть ваш бандл.
Почему же? Все сторонние бандлы, что вы используете в своем приложении отлично конфигурируются централизированно.
То, что внутри parameters.yml - это настройки конкретного окружения. Например доступы к конкретно вашей тестовой БД, конкретно ваш хттп домен и т.д. На продакшне parameters.yml будет свой.
Автогенерация нужна на этапе диплоя на дев машинах ваших колег. Что бы каждый руками этого не делал.
Нет. Вы используете бадл в своем приложении, и там же и конфигурируйте его. Сторонние бандлы по хорошему у вас все равно будут в vendor каталоге.
Я ж вам пример привел, как зарегать в вашем апликейшне сервис вашего капсуля. Какие бандлы, какие экстеншны, на кой оно вам надо? Хотите капсуль - юзайте капсуль, лишними обвязками вы только себе жизнь усложните.
Дык юзайте имя класса, в чем проблема?
Еще раз, если вы хотите создавать именно модули для публикации, без аппликейшнов - это одно.
Если вы хотите именно у себя в апликейшине это использовать - это совсем другое.
Для апликейшна НЕ НАДО ПЛОДИТЬ БАНДЛЫ, ваш аппликейшн уже таковым является.
Документация предлагает вам оформить настройки, которые требуются для собственного независимого бандла. Вы, как создатель бандла не знаете, да и не контролируете, откуда будут браться эти настройки, из yml, xml, env да хоть php.
Приведите пожалуйста пример, когда вам вот по зарез нужно получить именно контейнер, не сервис типа логгера, или вашего капсуля, а именно контейнер со всеми возможными зависимостями вашего проекта.
Настройки указываются в services.yml для конкретного сервиса, там где они будут использоваться. Зачем их прокидывать в верх, или вниз? Если вам надо одни и те же настройки для двух сервисов - в чем проблема, опишите для двух.
Если так, вам точно это нужно в одном проекте?))
Вы выбрали очень неудачное решение этой проблемы. Каждый пилит свою ветку, в момент, когда она готова - отправляется на ревью и вмердживается. Тот, кто последний должен втянуть себе изменения и пофиксить конфликты.