Какие есть плюсы/минусы composer?

Question

[Дмитрий Сонько]

В последнее время, данная тулза активно выбивается в тренды, однако рентабельность её использования до меня до сих пор не доходит. Для больших проектов с автодеплоем, масштабированием и тд он прекрасен. Запустилась нода, выгружаем код, запускаем композер, все заработало, но в чем кардинальная разница от билд серверов и тд, которые так или иначе разворачивают код на продакшене. Был бы очень благодарен за реальные кейсы использования сего.

Answer 1

[Юрий Ярош]

Проще всего сравнивать Composer c Bundler'ом.
Composer не является средством для деплоя или миграций типа Capistrano\Сapifony, его основной задачей является менеджмент зависимостей. Когда в либах находят дыры или правят баги и нужно быстренько обновить зависимости - лучше средства нет.

Comments

[Дмитрий Сонько]

Обычно это дело сразу правится в репозитории, и деплой сервер вытаскивает и раскидывает по серверам уже пофиксеный код. Зачем еще один инструмент? Хотелось бы посмотреть именно реальный кейс разработка-деплой-етк с использованием композера например

[Юрий Ярош]

В сам репозиторий проекта можно запихнуть зависимости выкачанные Composer'ом, и обновлять по мере необходимости меняя 2-3 цифры. Либо обновлять зависимости на целевой машине если их слишком много и раздувать репозиторий не целесообразно.

[Дмитрий Сонько]

В таком случае, это заменяет просто то, что надо идти на гитхаб, выкачивать, распаковывать и тд и тп, я правильно понимаю?

Answer 2

[Алексей Рехов]

Реальный кейс: в git репозитории хранится только папка application с вашими классами (контроллерами, моделями и т.п.). Все остальные библиотеки (включая сам фреймворк) другие разработчики и сервер получают сами - через composer update (install). Такой подход, во-первых, ускоряет автозагрузку классов, а во-вторых, позволяет одной строкой добавить новую библиотеку и сразу начать ее использовать.

Comments

[Дмитрий Сонько]

В таком случае, получается отдельно загрузчик композера, отдельно загрузчик фреймворка?

Answer 3

[Матвей Правосудов]

Дело в том, что нет альтернатив. А PECL/PHAR вообще трудно назвать расширениями (хотя они расширяют ядро, а не ваш код).

Answer 4

[Алексей Сундуков]

Не является он средством деплоя. Разумнее было бы его сравнивать с apt. И как раз в большом проекте, имхо, его польза под вопросом. Потому как в большом проекте автодеплой.