Composer ломается не в install, а в неверной структуре пакета и зависимостей

Если Composer ведёт себя странно, проблема часто не в нём, а в метаданных пакета. Проверь первым делом:
— composer.json: имя, тип, лицензия, autoload, require и conflicts
— PSR-4: путь и namespace должны совпадать без «почти»
— minimum-stability и prefer-stable: не загоняй проект в случайные dev-зависимости

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

Проверяй не только root-проект, но и то, что утащит твой пакет в чужой код:
— не переопределяй без нужды общие библиотеки
— не тащи в production лишние dev-required зависимости
— следи за автозагрузкой файлов и classmap, если пакет старый или нестандартный

Ещё одна типовая ошибка — обновлять всё подряд без фиксации границ. Для проекта полезнее короткая дисциплина: сначала composer validate, потом composer why и composer why-not, и только после этого правки в зависимостях.

Если держать пакет чистым на уровне метаданных, Composer становится скучным — а это лучший режим для деплоя.

Google ужесточает модерацию финансовой вертикали

Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …

➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali

🧠 Ещё больше инсайтов → в канале AFF.top

Composer ломает проект не из-за пакетов, а из-за того, как им пользуются

В Laravel/PHP-стеке Composer — не просто «установщик зависимостей», а точка, где фиксируется весь контракт проекта: версии, автозагрузка, платформенные ограничения и поведение скриптов.

Если нужен стабильный репозиторий, проверьте базовые вещи:
— lock-файл должен жить в VCS;
— диапазоны версий в composer.json не должны быть слишком широкими;
— platform.php помогает не поставить пакет, который не поедет на сервере;
— scripts и post-install команды не должны прятать бизнес-логику.

Частая ошибка — тянуть всё через dev-master и потом удивляться, почему на соседнем окружении проект ведёт себя иначе. Вторая — ставить пакет «на глаз», не глядя в его зависимости: один конфликт по symfony/polyfill или psr/container способен разнести весь граф.

Для командной работы полезно держать отдельный ритуал: обновление зависимостей делается через pull request, а не вручную на боевом сервере. Тогда можно увидеть, кто именно принёс изменение в дерево пакетов, и быстро откатить проблему.

Если Composer у вас работает только как install, проект уже живёт в зоне риска. Нормальная дисциплина — это lock, контроль платформы и регулярная проверка дерева зависимостей перед тем, как код попадёт дальше по пайплайну.

5 признаков хорошего PHP-пакета: на чём ломаются проекты после установки

Хороший пакет в Composer — это не тот, у которого красивая README. Это тот, который не начинает жить своей жизнью после первого же обновления.

Проверь пакет по пяти вещам:
— API: минимальный, понятный, без десятка «магических» методов.
— Зависимости: чем их меньше, тем проще сопровождать и переиспользовать код.
— Тесты: если покрыт только happy path, пакет уже требует осторожности.
— Сервис-провайдеры и конфиг: пакет не должен навязывать лишнюю инфраструктуру.
— Совместимость: если автор ломает публичные методы без миграции, это не «смелый рефакторинг», а риск для продакшена.

Отдельно смотрю на то, как пакет ведёт себя в Laravel-проекте:
— не тащит лишние фасады и глобальное состояние;
— не прячет логику в хелперах без возможности подмены;
— не конфликтует с очередями, событиями и автозагрузкой.

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

Перед установкой задавай один вопрос: смогу ли я сопровождать это через полгода, если автор исчезнет? Вот этот тест обычно честнее любой звезды на GitHub.

Filament ломают не кнопки: 5 правил, чтобы админка не превратилась в хаос

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

• Выноси бизнес-логику из ресурсов в сервисы или actions. Resource должен описывать форму и таблицу, а не решать, как считается статус заказа.
• Не плодите кастомные поля без причины. Часто хватает стандартных компонентов, а переусложнение делает поддержку дороже.
• Для больших таблиц сразу планируй фильтры, сортировки и eager loading. Иначе N+1 всплывает в самом неудобном месте.
• Политики и видимость действий проверяй на уровне модели, а не только в интерфейсе. Скрытая кнопка — не защита.
• Повторяющиеся схемы выноси в переиспользуемые классы или макросы, иначе каждая новая сущность будет копией предыдущей.

Есть наблюдение которое стоит проверить: Filament лучше всего работает там, где админка — это не отдельный продукт, а тонкий слой над доменной моделью. Чем меньше «магии» в ресурсах, тем проще тестировать, переиспользовать и передавать проект другому инженеру.

Если админка уже начала разрастаться, первым делом режьте дублирование и отделяйте домен от интерфейса — это экономит недели поддержки.

Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

🧠 Ещё больше инсайтов → в канале AFF.top

PHP-проект начинает тормозить не из-за фреймворка: проверьте эти 5 мест первым делом

Если в Laravel или Symfony “всё стало медленно”, причина часто не в роутинге и не в Eloquent. Обычно узкое место сидит рядом: в запросах, автозагрузке, кешах, очередях или файловой системе.

— Сначала смотрите N+1 и лишние eager load. Один «удобный» accessor на списке может превратить страницу в десятки запросов.
— Потом проверьте индексы и состав запроса: сортировка по неиндексированному полю, `LIKE '%...%'` и тяжёлые join’ы убивают ответ быстрее, чем любой сервисный слой.
— Дальше автозагрузка Composer: лишние пакеты, глубокие цепочки зависимостей и мусор в `autoload` бьют по времени старта каждого воркера.
— Не забудьте про кеши конфигурации и маршрутов: если приложение постоянно читает и собирает метаданные на лету, оно само себе создаёт лишнюю работу.
— И отдельно посмотрите на диск: логи, сессии, временные файлы, генерация изображений, синхронные записи в storage. I/O часто маскируется под “проблему PHP”.

Хорошая диагностика начинается с простого: замерьте время SQL, время PHP и время внешних вызовов отдельно. Тогда тормоз ищется не по ощущениям, а по факту.

Symfony ломается не в контроллере, а на границе между слоями

В проектах на Symfony чаще всего течёт не «фреймворк», а архитектурная дисциплина. Контроллер должен собирать вход, вызвать сервис и вернуть ответ; всё остальное уезжает в доменный слой, форму или отдельный handler. Как только в action появляются SQL, условные ветки по ролям и сборка HTML — код перестаёт быть тестируемым.

Есть три места, где стоит держать порядок:
— Request DTO или Form: валидация и нормализация входа
— Service/UseCase: бизнес-правило без HTTP-зависимостей
— Repository: только доступ к данным, без магии и сайд-эффектов

Ещё одна типовая ошибка — тащить container везде, где удобно. В Symfony это особенно соблазнительно, потому что сервисы рядом, но зависимость через контейнер скрывает контракт и усложняет тесты. Лучше явно прокидывать интерфейсы и держать сервисы маленькими: один класс — одна причина для изменения.

Если нужен быстрый аудит проекта, проверьте: есть ли у контроллеров только orchestration, можно ли поднять use case без ядра HTTP, и есть ли у каждого сервиса понятная зона ответственности. Там, где ответ «нет», и прячется будущий рефакторинг.

Composer ломается не из‑за пакетов, а из‑за дисциплины зависимостей

Если в проекте внезапно «поплыл» автолоад, сначала смотрите не на Composer, а на то, как живёт composer.json: • лишние прямые зависимости вместо транзитивных • версии без ограничений по смыслу • пакеты, которые тянут конфликтующие расширения PHP • ручные правки в vendor, которые потом никто не повторяет.

Вторая точка боли — lock-файл. Он нужен не «для галочки», а чтобы одинаково собирать проект на локали, в CI и на проде. Если composer.lock не коммитят, у команды будет каждый раз другой набор пакетов, а баги начнут выглядеть как магия.

Третье правило: ставьте обновления только через понятный сценарий. Сначала composer update конкретного пакета, потом тесты, потом проверка автозагрузки и конфликтов. Массовый update без причины почти всегда приносит больше шума, чем пользы. Ещё полезно держать под рукой composer validate и composer diagnose — они быстро находят мусор в конфиге и проблемы среды 🔧

Итог простой: Composer хорош там, где зависимости описаны аккуратно, lock-файл живёт в репозитории, а обновления идут по одному пакету, а не по принципу «потом разберёмся».

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

🧠 Ещё больше инсайтов → в канале AFF.top

Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

🧠 Ещё больше инсайтов → в канале AFF.top

Filament ломается не в CRUD, а в связке форм, policy и действий

Если Filament начал вести себя «странно», обычно проблема не в самом админ-UI, а в трёх местах: авторизация, состояние формы и побочные действия. На ровном CRUD это не видно, но как только появляются зависимости между полями, вложенные relation manager и массовые операции — всплывает реальная архитектура.

Проверь базовый порядок:
— доступ к ресурсу и странице отдельно от доступа к записи;
— hidden/disabled поля не должны быть единственным источником бизнес-логики;
— валидация должна жить не только в форме, но и на уровне модели или сервиса.

Частая ошибка — дублировать правила в каждом action. Тогда один create работает, а edit, bulk action или modal action обходят ограничение. В Filament лучше вынести правило в одно место и использовать его везде, где меняется доменная сущность.

Ещё одна зона риска — тяжёлые вычисления в `afterStateUpdated`. Если поле тянет расчёты, запросы или цепочку зависимых обновлений, интерфейс начинает «тупить» и ловить неожиданные циклы. Здесь помогает простой принцип: форма собирает данные, сервис их обрабатывает.

Если админка стала хрупкой, сначала упрости связь между UI и доменом. Filament любит чистые границы — и резко хуже переносит бизнес-логику, размазанную по полям, actions и страницам.

Composer ломает проект не в vendor, а в привычках команды

За неделю в репах: половина «странных» багов после установки пакетов — это не пакет, а дисциплина вокруг Composer.

• Не коммитьте vendor, если у вас не зафиксирован особый сценарий деплоя.
• Всегда храните composer.lock в репозитории: без него вы не воспроизводите сборку.
• Не правьте зависимости руками в JSON, если можно использовать require/update/remove и сразу проверять конфликт.

Ещё три места, где обычно прячется боль: autoload, scripts и платформенные требования. Если PSR-4 маппинг расходится с реальной структурой, классы «пропадают» только на части окружений. Скрипты удобны, пока в них не складывают всё подряд: лучше держать там тонкие команды, а бизнес-логику — в коде. platform.php и ext-список помогают поймать несовместимость до выката, а не после.

Полезная привычка: перед merge прогоняйте composer validate, composer install и проверку автозагрузки в чистом окружении. Если проект большой, отдельно фиксируйте набор пакетов для dev и production — так проще понять, откуда пришла поломка.

Composer не про «поставить пакет», а про воспроизводимость. Чем раньше команда это принимает, тем меньше сюрпризов на стенде и в проде.

Spatie в Laravel: 6 пакетов, которые экономят недели на типовом PHP-стеке

Если в проекте уже есть auth, очереди и нормальный деплой, Spatie закрывает скучную, но дорогую часть разработки. Ставка обычно делается не на «магический пакет», а на набор узких инструментов, которые не конфликтуют друг с другом.

Что чаще всего берут в прод:
— spatie/laravel-permission для ролей и прав без самописной таблицы ACL
— spatie/laravel-medialibrary для файлов, превью и коллекций медиа
— spatie/laravel-query-builder когда API уже выросло и фильтры надо стандартизировать
— spatie/laravel-activitylog если нужен аудит действий, а не «смотрим по логам сервера»
— spatie/laravel-backup чтобы бэкап был частью приложения, а не надеждой на хостинг

Есть наблюдение которое стоит проверить: Spatie лучше всего работает там, где вы не пытаетесь натянуть пакет на хаос. Сначала задайте модель данных и правила доступа, потом подключайте пакет. Иначе получаются красивые фасады поверх путаницы.

Перед внедрением проверьте три вещи: конфликты с кастомными политиками, нагрузку на файловое хранилище и то, как пакет ведет себя в тестах. Особенно это важно для MediaLibrary и Permission — оба любят, когда у проекта уже есть дисциплина в моделях и миграциях.

Если нужен быстрый эффект без переписывания ядра, начинайте с permission и query builder: они дают порядок в самом проблемном месте и не требуют менять весь домен.

Livewire тормозит не из-за фреймворка, а из-за лишних перерисовок и тяжёлых хендлеров

Livewire удобно тащит состояние в PHP, но за это платит частыми запросами и повторным рендером. Если компонент начинает «думать» на каждый чих, UI быстро превращается в кашу.

Проверь базовые вещи:
— не вешай на один компонент и форму, и фильтры, и таблицу;
— выноси тяжёлые вычисления в сервисы, а не в методы рендера;
— не гоняй в `wire:model` всё подряд, когда достаточно `defer` или ручного `submit`;
— для больших списков сразу используй пагинацию, а не попытку показать всё на одном экране.

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

Если нужен живой интерфейс без сюрпризов, держи компонент коротким: одна зона ответственности, минимум скрытой логики, максимум предсказуемых запросов. В Livewire это работает лучше любой «магии».