Spatie экономит недели, если не тащить пакет «на всякий случай»

Spatie экономит недели, если не тащить пакет «на всякий случай»

У Spatie сильная привычка решать одну задачу очень чисто: медиа, permissions, settings, activity log, query builder, backups, data export. Но главный риск не в пакете, а в том, что его начинают ставить раньше, чем описан процесс в проекте.

Перед подключением проверьте три вещи:
• где живёт источник правды — в БД, файловой системе или конфиге;
• кто владеет данными и как они очищаются;
• что будет, если пакет удалить без миграции формата.

У Spatie почти всегда есть удобный фасад, но не всегда стоит прятать за ним доменную логику. Если пакет отвечает за инфраструктуру — отлично. Если через него начинают описывать бизнес-правила, проект быстро становится хрупким. Вынесите критичную логику в свои сервисы, а пакет оставьте как адаптер.

Ещё одна типовая ошибка — использовать «готовое» API без чтения edge cases: очереди, транзакции, кастомные диски, soft delete, multi-tenant. Именно там всплывает 80% боли, а не в базовом примере из README.

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