Александр Ме

abstract class Model {
   verify() {
      const name = this.getName()
   }

   abstract getName(): string;
}

class User extends Model {
   private name = 'Boris'
   override getName() { return this.name; }
}

Нужно. Назови это чем-то типа "анализ и уточнение технического задания, и составление плана работ " назначь цену изходя из размера ТЗ и количества необходимых созвонов и доработок.

Дай скидку, если в итоге решите сотрудничать.

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

Если скажет что другие исполнители не берут деньги за это - напомни про скидку и скажи, что это тоже работа и оно позволяет точнее предсказать цену и, меньше затягивать сроки, и не делать лишних правок ближе к концу проекта.

На сайте используется TLS Fingerprint (вероятно, JA3) как один из индикаторов сессии в системе перед веб-сервером, вероятно, это анти-DDoS.
Так как браузер и curl используют разные SSL-библиотеки и передают разные наборы шифров, сервер предлагает вам пройти challenge.

Модульный подход не исключает использования штатной папки app и остальных, в том числе resources. Общие, базовые стили вполне могут располагаться там.

Не совсем понял зачем так делать,

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

В любой непонятной ситуации смотри исходники =)

https://github.com/laravel/framework/blob/10.x/src...

Такой тонкой настройки нет.
Такой вариант выбран, потому что он универсален, подходит для любого доктайпа.

"Cгенерировать composer.json с уже установленными в нем зависимостями" невозможно.
Потому что файл composer.json не устанавливает никакие зависимости. Это делает сам композер, соответствующей командой.

Если вам нужен composer.json с прописанными в нем пакетами, то composer.json собственно и предназначен для того, чтобы прописывать в нем зависимости. Так работают 100% приложений, использующих композер - в их дистрибутивах лежит файл composer.json, в котором прописаны зависимости. Если, как вы говорите. во всех проектах используются одни и те же зависимости, вы можете взять файл от любого проекта и добавить его в репозиторий.

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

composer init --name='gordinskiy/new_package' \
    --description='Project description' \
    --type='library' \
    --author='Dmitriy Gordinskiy' \
    --license='MIT' \
    --require='php:>=8.2' \
    --require='webmozart/assert:^1.11' \
    --require-dev='phpunit/phpunit:^10.3' \
    --require-dev='vimeo/psalm:^5.11' \
    --require-dev='phpstan/phpstan:^1.10'

На этом бы всё закончили, но есть ощущение, будто у него осадочек остался

Это исключительно твоё ощущение.
Ты и так очень мало денег попросил, особенно с учётом стека и проделанной работы на ресёрч, которую так-то тоже считать надо.

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

Язык, конечно, ты изначально выбрал не самый быстрый для написания кода, но не думаю, что выбор какого нибудь js или python сильно бы сказался на этом.

Просто не давть пользователю повторно тыкать там, где это вызовет повторный запрос, пока идёт загрузка текущего?

Но если хочется быть ленивым - можно просто обернуть запросы в leading debounce-promise.

Все эти thunk и saga - полная ересь, порождённая богомерзким redux.

Но костыль это или нет - решать вам. Что скажете?

Скажем, что нам пофиг, что происходит в вашем коде ¯\_(ツ)_/¯

Но есть два точно некостыльных решения: View Composers и Service Injection.

P.S. Мы не теряем надежды, что когда-нибудь вы всё-таки прочитаете документацию по вашему основному рабочему инструменту.

https://medium.com/@dan_abramov/making-sense-of-re...
Заметка от Дена Абрамова.
Есть очень редкие кейсы, которые пока невозможно реализовать функциональными компонентами и хуками, они описаны в документации, в остальных случаях советую предпочесть функциональные компоненты и хуки. "Углубляться" нужно в оба подхода, все углубление состоит в том, что ты хорошо должен знать жизненный цикл компонентов, при чем депрекейтед тоже, хотябы чтобы уметь отрефакторить старый код, но если ты пишешь новый компонет - пиши его в функциональном стиле.

Что это за сущности - Content и ContentTag?

Теги реализуются связями M2M

Таблицы:
tags
id | text

contents
id | content | …

content_tag
tag_id | content_id

class Content extends Model {
  public function tags(): BelongsToMany {
    return $this->belongsToMany(Tag::class);
  }
}

class Tag extends Model {
  public function contents(): BelongsToMany {
    return $this->belongsToMany(Content::class);
  }
}

dd($content->tags);

PS
А если предполагается наличие других сущностей, подлежащих тегированию, то необязательно под каждую делать отдельную таблицу тегов. Можно воспользоваться полиморфными связями.

PPS
Подробности в документации. https://laravel.com/docs/10.x/eloquent-relationships