В этом сервисе упор был на то, чтобы у пользователя не было лишних зависимостей: только скачать ZIP и запустить docker compose. Спасибо за вариант, про Copier не знал - полезно!
Спасибо за идею с Makefile и make init - одну точку входа действительно удобно иметь. По поводу переноса тяжёлых процессов на получателя: чтобы в проекте был composer.lock (воспроизводимые сборки), composer install на сервере в любом случае нужен - без него lock не получить. Значит, от того, что получатель дополнительно запускает composer install по make init, нагрузка с сервера не снимается, выигрыш в основном в размере архива (не кладем vendor/ в ZIP). Для такого утилитарного стартера это не такой уж большой выигрыш, а усложнять логику не хочется.
Совершенно верно - и #[MapRequestPayload] с автовалидацией, и централизованная обработка через kernel.exception - это стандартные инструменты Symfony. Ваш пример хорошо показывает, что в рамках одного проекта можно обойтись без дополнительного бандла и держать всё под контролем. Собственно, я и сам делал именно так - через subscriber с маппингом исключений и единым JsonResponse. Бандл решает немного другую задачу. Он не добавляет новую механику поверх Symfony, а упаковывает уже существующие практики в переиспользуемый слой. Когда проектов становится много (микросервисы, разные команды, разные подрядчики), важна не просто централизованная обработка ошибок, а гарантированная консистентность формата ответов между сервисами - без копирования listener’ов из проекта в проект и без постепенного "дрейфа" структуры. В случае с ExceptionResponseSubscriber его действительно несложно написать. Сложнее - поддерживать синхронность изменений между несколькими репозиториями, когда формат ответа эволюционирует. Кстати, по RFC 7807 - идея хорошая! Если кому-то нужен полноценный problem+json технически это реализуемо через ResponseFactoryInterface который уже есть в бандле. Можно добавить ProblemDetailsResponseFactory как альтернативную реализацию и переключать через конфиг (format: problem+json). Единственный нюанс - RFC 7807 стандартизирует только формат ошибок, для успешных ответов общего стандарта нет, поэтому это скорее опциональный режим, а не замена дефолтному формату. Если будет запрос - реализовать несложно. В общем, ваш подход полностью корректен для проекта, где всё находится под контролем одной команды. А бандл может быть полезен там, где нужна стандартизация между несколькими проектами "из коробки".
Спасибо за конкретику - всё по делу. По.gitattributes, export-ignore и recipes принято, это очевидный пропуск. По поводу версий - это ошибка, не намерение. Я случайно запинил 7.4.* вместо ^7.4|^8.0. Бандл не использует deprecated API, поэтому Symfony 8.0 поддерживается без изменений кода.
В этом сервисе упор был на то, чтобы у пользователя не было лишних зависимостей: только скачать ZIP и запустить docker compose. Спасибо за вариант, про Copier не знал - полезно!
Спасибо за идею с
Makefileи make init - одну точку входа действительно удобно иметь. По поводу переноса тяжёлых процессов на получателя: чтобы в проекте былcomposer.lock(воспроизводимые сборки), composer install на сервере в любом случае нужен - без него lock не получить. Значит, от того, что получатель дополнительно запускает composer install по make init, нагрузка с сервера не снимается, выигрыш в основном в размере архива (не кладемvendor/в ZIP). Для такого утилитарного стартера это не такой уж большой выигрыш, а усложнять логику не хочется.Совершенно верно - и
#[MapRequestPayload]с автовалидацией, и централизованная обработка черезkernel.exception- это стандартные инструменты Symfony. Ваш пример хорошо показывает, что в рамках одного проекта можно обойтись без дополнительного бандла и держать всё под контролем. Собственно, я и сам делал именно так - через subscriber с маппингом исключений и единым JsonResponse.Бандл решает немного другую задачу. Он не добавляет новую механику поверх Symfony, а упаковывает уже существующие практики в переиспользуемый слой. Когда проектов становится много (микросервисы, разные команды, разные подрядчики), важна не просто централизованная обработка ошибок, а гарантированная консистентность формата ответов между сервисами - без копирования listener’ов из проекта в проект и без постепенного "дрейфа" структуры.
В случае с
ExceptionResponseSubscriberего действительно несложно написать. Сложнее - поддерживать синхронность изменений между несколькими репозиториями, когда формат ответа эволюционирует.Кстати, по RFC 7807 - идея хорошая! Если кому-то нужен полноценный
problem+jsonтехнически это реализуемо черезResponseFactoryInterfaceкоторый уже есть в бандле. Можно добавитьProblemDetailsResponseFactoryкак альтернативную реализацию и переключать через конфиг (format: problem+json). Единственный нюанс - RFC 7807 стандартизирует только формат ошибок, для успешных ответов общего стандарта нет, поэтому это скорее опциональный режим, а не замена дефолтному формату. Если будет запрос - реализовать несложно.В общем, ваш подход полностью корректен для проекта, где всё находится под контролем одной команды. А бандл может быть полезен там, где нужна стандартизация между несколькими проектами "из коробки".
Спасибо за конкретику - всё по делу. По
.gitattributes,export-ignoreи recipes принято, это очевидный пропуск. По поводу версий - это ошибка, не намерение. Я случайно запинил7.4.*вместо^7.4|^8.0. Бандл не использует deprecated API, поэтому Symfony 8.0 поддерживается без изменений кода.