Я не буду писать как пользоваться composer, но хочу поделиться своей практикой. Надеюсь, мои советы окажутся кому-то полезны.
Используйте меньше пакетов, чем меньше - тем лучше.
Если вы можете обойтись без пакета - обойдитесь. Лучше собственный сервис или компонент. Нет, это не изобретение велосипеда. Во-первых, научитесь писать свои компоненты, во-вторых - это надежнее. Пакет имеет смысл реквайрить только если вы находитесь в очень агрессивной разработке или это вам сэкономит несколько недель. 95% всех публичных проектов мусор, и 80% перестанет поддерживаться в ближайшие 5 лет.
Некоторые зависимости создают такую связность в коде, что избавление от них превращается в огромную проблему(прим: валидация, формы, апи-компоненты, ORM).
Мелкие пакеты просто копируем в код.
Рано или поздно, если наш проект живёт достаточно долго, мы сталкиваемся с неприятной ситуацией, что пакет стал abandoned, т.е. потерял своего контрибьютера, больше не обновляется, и самое главное - стал несовместим с новыми версиями php. Очевидным "умным" решением становится сделать форк и поддерживать версию самому. На самом деле нужно просто сделать ctrl+c ctrl+v, забыв навсегда о необходимости обновлять его версию. Рекомендуется так сделать изначально, не дожидаясь проблемы: видим небольшой пакет, или большой, но с небольшим фрагментом нужного вам функционала, сразу копируем нужную часть в структуру проекта.
Дополнительным плюсом будет возможность изменить код, приведя в соответствие с вашими требованиями.
Когда и как обновляться
Когда вы делаете обновление одного отдельно взятого пакета, вы рискуете что новый баг сломает часть вашей системы. Поэтому обновлять пакет нужно только если у вас есть убедительная причина.
Пример убедительный причин обновить пакет:
появление новой фичи, которая вам нужна
закрытие уязвимости
performance boost
обновление как зависимости, например, при обновлении версии php
В эти моменты вы будете рады, если у вас есть тесты
Обновление symfony, laravel и php
В целом правило такое, что php обновляется после второго патча минорной версии, чтобы не словить лютый баг php рантайма в проекте(8.0.2, 8.1.2 ....)
Symfony предлагает LTS(long term support) версии, на них нужно ориентироваться, как только такая версия вышла стоит добавить задачу в бэклог.
Никаких внезапных обновлений пакетов быть не должно. Либо мы работаем с техдолгом и делаем upgrade, либо обновляем пакет в рамках задачи, в которой это требуется.
Laravel обновляется раз в год, оптимально обновляться раз в год, обычно оно того стоит. И/или если вам страшно нужна какая-то новая фишка. Накапливание отставания влечет за собой проблемы в дальнейшем.
Не забудьте почитать patch notes, возможно вы сможете улучшить ваш проект новыми фичами.
Последовательность при обновлении php:
Сперва обновляем версию php, потом подтягиваем новые версии основных компонентов(laravel, symfony), потом остальное. Неизбежно мы сталкиваемся с конфликтами, тут вылезут все abandoned репозитории, и пакеты с тормозным обновлением версий.
-W опция позволяет обновить пакеты вместе с зависимостями. Если обновление кусочками не получается, начинаем собирать проект в composer заново. Выписываем все используемые пакеты и реквайрим их поочередно.
Можно реквайрить несколько пакетов сразу, через пробел.
Стратегия работы с composer.lock
сomposer.lock должен быть в репозитории. Это обеспечивает предсказуемость окружения. Лучшей практикой является идентичность серверной и локальной среды(и всех других сред, в которых работает программа).
Как мерджить composer.lock в случае конфликта? - при мердже генерим .lock заново, также можно просто обновить hash "composer update --lock"