d-sem

1. Фрилансер - это черная дыра. Нет никаких гарантий, что вы с первого раза найдете хорошего специалиста. Вы потратите массу времени походив по рукам как портовая путана, потеряете массу времени и сил. В итоге скорее всего специалиста вы найдете, но какой ценой?

2. Нет слово бесплатно. Бесплатно будут работать только молодые специалисты, которых вы воспитаете. И то не долго, постепенно их интерес и отеческие симпатии пропадают, люди имеют свойство развиваться.

3. Дешевые предложения на фрилансе можно сразу отметать, шанс, что эти специалисты чего-то могут резко приближается к нулю. Нормальные же предложения по стоимости приближены к студийным.

Вывод: Строить свою веб-студию можно только из своих коллег по цеху с которыми вы уже работали. Для этого желательно самому побыть фрилансером или же поработать в студии. Однако помимо кадровой работы у вас должна быть тонна знаний из разряда всего понемногу. Иначе вы останетесь без денег с лапшой на ушах

https://laravel.com/docs/7.x#installing-laravel

В целом правильно, неплохая проработка материала.
У меня есть только пара замечаний, не относящихся напрямую к централизованному обработчику.

• error_reporting(E_ALL & ~E_NOTICE); делать не стоит. Если только не приходится работать с адовым легаси, которое сыпет нотисами, лучше отлавливать все ошибки. Учитывая же что в 8-ке обращение к несуществующей переменной станет не нотисом а предупреждением, такая конструкция со временем станет бессмысленной. что означает - ошибки надо исправлять, а не замалчивать.
  
• ini_set("error_log", __DIR__ . "/php-errors.log"); будет не очень хорошей идеей, если файл error-handler.php выше корня веб-сервера. Ошибки надо прятать подальше.
  
• ini_set('display_startup_errors', 1); - это какая-то дичь, которая кочует из руководства в руководство. Никто никогда этих стартап еррорс не видел, но многие старательно пишут это заклинание у себя в коде. Это по-любому связано с настройкой сервера, и в отладке ошибок поможет примерно ничем.
  
• само по себе задание настроек через ini-set ненадежно. Ошибка может случиться до того, как РНР прочитает эту команду. Задавать надо в конфигурации веб-сервера.
  
• в теории можно добавить флаг или автоматическую проверку на джейсон запрос. и соответственно кодировать ответ в джейсон. Но это только для криовруких фронтендеров, которые не умеют читать НТТР статусы, а ждут что им все разжуют в джейсоне, и без error: true они не поймут, что была ошибка
  
• стек вызовов может быть довольно длинным, и раздувать логи. Можно подумать о более укороченном варианте.
  

Вообще всё зависит от задач. Например все современные фреймворки в режиме разработки выдают развесистую страницу с отчетом об ошибке, которая включает в себя и кусок кода вокруг строи, на которой произошла ошибка.
Но как именно базовый обработчик, необходимый минимум - вполне годно.

Я только не понял, почему вопрос про error_handler. Что именно смущает?

Добавьте use.

// Прописан в алиасах
use URL;
// Или полный путь
use Illuminate\Support\Facades\URL;

локальное хранилище или куки. Сложней есть способы - но тебе их незачем пока

куки , ну или серьезнее: авторизация, сервер, БД

Можно ли обойтись обычным js?

Можно. TypeScript лишь добавляет к JavaScript статическую типизацию в компайл-тайм. После компиляции будет все тот же JS.

Какие будут плюсы?

Главный плюс, ИМХО, - скорость разработки за счет подсказок IDE и автодополнения, больше авторефакторингов. Ну и возможность ограничить использование функций/методов от нежелательного использования тоже плюс. А если еще и проектировать доменную модель на типах, то можно сразу видеть, если что-то не сходится, еще до написания логики.

Не будет ли много лишней писанины по сравнению с чистым js?

Большинство типов TypeScript способен вывести. Далеко не Хиндли-Милнер конечно, но тоже хорошо. Я пишу больше в ФП стиле, с редкой примесью структурно-процедурного при описании эффектов, так у меня явные указания типов присутствуют только в сигнатурах функций. В самой логике код неотличим от обычного JS, но с хорошей проверкой типов.

Будет ли сложно хранить скомпилированный js?

Как и любые другие артефакты сборки, скомпилированный JS хранить не нужно. Компилируйте непосредственно перед выкладыванием на продакшен, а в git храните лишь TS код + настройки компилятора. А в dev среде вообще можно запускаться через модуль ts-node.

потянет