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

Используйте меньше пакетов, чем меньше - тем лучше.
Если вы можете обойтись без пакета - обойдитесь. Лучше собственный сервис или компонент. Нет, это не изобретение велосипеда. Во-первых, научитесь писать свои компоненты, во-вторых - это надежнее. Пакет имеет смысл реквайрить только если вы находитесь в очень агрессивной разработке или это вам сэкономит несколько недель. 95% всех публичных проектов мусор, и 80% перестанет поддерживаться в ближайшие 5 лет.

Некоторые зависимости создают такую связность в коде, что избавление от них превращается в огромную проблему(прим: валидация, формы, апи-компоненты, ORM).

Мелкие пакеты просто копируем в код.
Рано или поздно, если наш проект живёт достаточно долго, мы сталкиваемся с неприятной ситуацией, что пакет стал abandoned, т.е. потерял своего контрибьютера, больше не обновляется, и самое главное - стал несовместим с новыми версиями php. Очевидным "умным" решением становится сделать форк и поддерживать версию самому. На самом деле нужно просто сделать ctrl+c ctrl+v, забыв навсегда о необходимости обновлять его версию. Рекомендуется так сделать изначально, не дожидаясь проблемы: видим небольшой пакет, или большой, но с небольшим фрагментом нужного вам функционала, сразу копируем нужную часть в структуру проекта.

Дополнительным плюсом будет возможность изменить код, приведя в соответствие с вашими требованиями.

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

Пример убедительный причин обновить пакет:

1. появление новой фичи, которая вам нужна

2. закрытие уязвимости

3. performance boost

4. обновление как зависимости, например, при обновлении версии 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

1. сomposer.lock должен быть в репозитории. Это обеспечивает предсказуемость окружения. Лучшей практикой является идентичность серверной и локальной среды(и всех других сред, в которых работает программа).

2. Как мерджить composer.lock в случае конфликта? - при мердже генерим .lock заново, также можно просто обновить hash "composer update --lock"