Alex Wells

Не надо! Не делайте! Выглядит эффектно, но на этом все. Скроллить это бесконечно - тошнит.

return (isSidesParallel(sideAb, sideCd) && !isSidesParallel(sideBc, sideDa)) || 
    (!isSidesParallel(sideAb, sideCd) && isSidesParallel(sideBc, sideDa));

и are sides parallel, а не is

В смысле? Ты хочешь, что бы какой-то "пакет" сам придумал текст ошибки, исходя из контекста кода что ли? Сам понимаешь то, чего ты хочешь?

Хочешь нормальные ошибки - ну напиши обработчик, как тебе советуют, и отдавай юзеру какие хочешь ошибки. А в кастомных случаях - кидай ексепшен и выводи.

В чем проблема? Никаких пакетов нет и быть не может, ведь это ТВОЯ задача как программиста в конкретном проекте с конкретной бизнес логикой.

horizon и пишешь свой балансер к нему.

Скриншот отправляй... либо так, либо ты верстаешь письмо.

Зачем тебе active в принципе? Почему ты в выборках не можешь просто юзать updated_at где тебе нужно? Судя по тому, что ты задаешь этот вопрос, никаких причин нет.

Руками написать код.

https://laravel.com/docs/7.x/database

DB::table()
    ->update()
    ->where()

Из коробки - нет, нельзя.

Фасады, хелперы, app(Dep::class), resolve(Dep::class) и подобные вещи - это ок ровно до того момента, пока ты не захочешь отделить логику от фреймворка (что бы мигрировать на другой фреймворк или другой язык программирования).

Юнит-тестить без привязки к контейнеру - тоже сильно удобней.

php artisan view:clear
php artisan route:clear

Открой документацию и почитай про query builder.

Очень интересно (нет).

Очереди запусти.

Опишите ДТОшку (тупо класс с филдами) и сериализуйте на фронте, десериализуйте (мапьте) на бэке.

На бэке может выглядеть как:

data class SomeRequestDTO(val name: String, val surname: String, val photo: Photo)

и какой-нить маппер, который автоматически это все замапит куда нужно.

Сделать раут, который матчит вообще все, и разбиратся уже в контроллере.

{$_FILES['input-file']}";
Даже интересно, какой вывод от этого ты ожидал?