<b>10 PHP-пакетов, которые стоит держать в базе любого проекта</b>

<b>10 PHP-пакетов, которые стоит держать в базе любого проекта</b>

За неделю в репах чаще всего всплывают одни и те же решения: логирование, очереди, даты, HTTP-клиенты, экспорт и валидация. На этом месте полезно не «искать по звёздам», а собрать свой минимальный набор и не спорить с каждым новым багом.

— <code>spatie/laravel-permission</code> — роли и права без самописной каши
— <code>spatie/laravel-data</code> — DTO и маппинг входных данных
— <code>laravel/horizon</code> — если очереди уже стали отдельным продуктом
— <code>guzzlehttp/guzzle</code> — когда нужен контроль над HTTP
— <code>nesbot/carbon</code> — даты, которые не хочется ненавидеть
— <code>monolog/monolog</code> — нормальная структура логов
— <code>maatwebsite/excel</code> — импорт и экспорт без ручной боли
— <code>barryvdh/laravel-debugbar</code> — чтобы ловить лишние запросы
— <code>phpunit/phpunit</code> — базовый щит от регрессий
— <code>symfony/console</code> — если в проекте есть серьёзные CLI-скрипты

Есть наблюдение которое стоит проверить: пакет нужен не потому, что он популярный, а потому что он сокращает ваш собственный код и делает поведение предсказуемым. Если библиотека добавляет магию, которую потом трудно тестировать и обновлять, она скорее мешает.

Перед подключением смотрите на три вещи: активность репозитория, размер поверхности API и наличие точек расширения. Хороший пакет не заставляет вас подстраивать архитектуру под себя — он встраивается в неё и остаётся заменяемым.

Соберите свой «белый список» из 8–12 пакетов и отдельно держите список запрещённых приёмов: это экономит часы на ревью и уменьшает техдолг уже в первый месяц.