Использование composer в проекте php для начинающих
Я не буду писать как пользоваться 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»
