Не понял прикола с установкой 4.0.2 для приложений. Понимаю, что перевод, но все же.

Вы правда читаете все ченджлоги и дифы всех зависимостей каждый день, чтобы понять, надо вам обновляться или нет? Вы в курсе, что транизитивные зависимости вы все равно так не ограничиваете и composer update таких «зафиксированных» зависимостей все равно вам все может «сломать». А если вы зафиксируете еще и все транзитивки (в чем я сомневаюсь, т.к. они еще и меняться имеют свойство), то вы по сути получите тот же Lock файл

Гораздо проще и правильней выставлять ограничение с помощью каретки (или суровей — тильты на minor.major.patch), типа "~4.0.2", и запускать composer update попакетно — типа composer update symfony/symfony. В таком случае вы обновляетесь только в пределах одного пакета и только в пределах его новых патч. релизов (которые не должны ничего ломать, а только фиксить). Если нужно притянуть также зависимости пакета — флаг --with-dependencies

Из полезных советов могу предложить тулзу composer-lock-diff, очень удобно прикладывать к пулл-реквестам внутри команды.
Если нужно проанализировать YAML-файлы, то определяйте зависимость, например, так: «symfony/yaml»: «4.0.2».
Неправильно.
Если вы боитесь нарушения BC в минорных версиях критического пакета, то хотя бы не фиксируйте патч-версию.
Допустимо будет так: «symfony/yaml»: "^4.0.2".

А еще лучше нормально покрывать приложение тестами и фиксировать только мажорную версию.
Допустимо будет так: «symfony/yaml»: "^4.0.2".


Это кстати не фиксирует минорную версию. Проверить можно здесь

jubianchi.github.io/semver-check

4.2.0 satisfies constraint ^4.0.2
Спасибо, с тильдой, конечно же: «symfony/yaml»: "~4.0.2".
А с "^" уже при нормальном покрытии тестами.
Вы ошибаетесь, "symfony/yaml": "^4.0.2" обновит yaml вплоть до следующей мажорной версии, то есть 5.0.0. Чтобы получать только патчи, нужно фиксировать так: "symfony/yaml": "~4.0.2" или так: "symfony/yaml": "4.0.*".
Совет № 6: в библиотеках кладите composer.lock в .gitignore

Тоже не всегда так: например для библиотек распространяемых через compose и phar.

Библиотека, распространяемая через phar — это инструмент, целостный и законченный, по сути является полноценным проектом. Но и в этом случае смысл сомнителен, если есть хорошее покрытие тестами, то гораздо удобней при сборке очередной версии инструмента забрать как минимум последний патч-релиз из имеющихся, а это уже повод не хранить лок. phpunit, например, при сборке phar делает update (если верить build.xml)

github.com/sebastianbergmann/phpunit/blob/master/build.xml#L54
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.