Поскольку файл не используется каким-либо полезным образом при установке пакета, как функциональность самой библиотеки для конечного пользователя, он, по крайней мере, не имеет отношения к пользователю библиотеки.
Затем рассуждение сводится к тому, полезно ли разработчикам библиотеки иметь заблокированный набор зависимостей, необходимых им для выполнения задач разработки, например, c версий фреймворков тестирования и c. В этих случаях аргумент может заключаться в том, что файл composer.json выполняет ту же роль, что и в обычном приложении - он блокирует зависимости от тех, которые, как мы знаем, работают.
Однако здесь есть предостережение - при разработке библиотеку, которую вы на самом деле хотите, чтобы вариант использования был таким же, как у пользователя библиотеки, когда он / она устанавливает ее. Учитывая это, обычно имеет смысл заблокировать явную версию в composer.json вместо того, чтобы полагаться на файл блокировки для обеспечения той же функциональности. Это заставляет любое решение CI устанавливать правильный набор (такой же, какой получил бы пользователь) зависимостей при запуске тестов. Однако вы можете заставить этот процесс обновлять файл блокировки локально перед запуском тестов, чтобы иметь несколько тестовых случаев - один с заблокированными зависимостями, а другой с самыми последними версиями (как пользователь мог бы получить).
Doctrine принял решение, что файлы блокировки должны быть зафиксированы по их собственным причинам, которые вполне допустимы - по сути, они сводятся к инструментам, используемым для их рабочих процессов разработки:
Все Doctrine проекты должны зафиксировать файл composer.lock. Такие инструменты, как phpstan и phpcs, довольно сильно отличаются от agile в выпусках исправлений, и мы не хотим, чтобы сборки начинали давать сбой без внесения каких-либо изменений в наш собственный код. Всякий раз, когда требуется обновить зависимость, файл composer.lock должен быть обновлен локально, а изменение отправлено через запрос на вытягивание.
В обоих случаях можно указать аргумент; это будет зависеть от предпочтений самого проекта и его разработчиков. Я склоняюсь к тому, чтобы это не выполнялось, поскольку это более точно повторяет то, что пользователь будет испытывать при установке библиотеки. Однако для каждого разработчика по-прежнему будут присутствовать локальные файлы блокировки, а это означает, что то, что каждый разработчик имеет на своем компьютере при разработке библиотеки, может отличаться. Фиксация файла блокировки сделает это более похожим для всех разработчиков, но потребует особой осторожности, чтобы воспроизвести опыт для пользователей (а затем мы снова вернемся к нашим исходным аргументам ...).