Tony Soloveyv

Можно. Не открывать много вкладок

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

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

Либо, чтобы из репы можно было скопировать лишь dist/ и сразу опубликовать это как приложение в любом месте, без дополнительных команд.

От такого способа не будет видно, что применялся Реакт?

Слепой не увидит ничего, в остальном - все чекается на раз-два.

Рекомендую изучить крупные репы и обратить внимание на то, что там в рамках одной репы имеются исходники (src), сборки разных видов (dist/build), опубликованы все необходимые команды так, чтобы даже не зрячая обезьянка могла скопировать и выполнить эту команду, чтобы получить желаемый результат.

Устанавливай .NET Core и разрабатывай на здоровье.
Разница с Windows разве что в отсутствии оконных приложений, а остальные типы проектов есть.

P.S. Visual Studio придется забросить и перейти либо на VS Code либо на Rider

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

В зависимости от возможностей хостинга, файлы хранят либо локально(в случае например собственного выделенного сервера и наличия райд стойки), либо, как уже написали, в облачных хранилищах, что чаще всего достаточно выгодно в плане денег за объем/трафик, плюс расширение хранилища будет просто отражаться на счете за услуги, а не ложиться ответственностью на вас как владельца сгоревших винтов с данными клиента. АПИ у всех весьма несложные, а драйвера для работы с удаленными файлохранилищами есть практически для всех популярных движков в виде готовых пакетов.

Почему C# не кроссплатформенный?

На этот вопрос нельзя ответить сразу по двум причинам:
1. C# - это язык, а язык не может быть кросс-платформенным, так как платформы в разрезе языка и нет.
2. .NET уже много лет как кросс-платформенный.
Начиная с уже мейнстримного .NET 8, заканчивая mono и всякой экзотикой типа nano framework

но при этом, это не так

Ничто нельзя запустить на "чём угодно"

но в неё вопрос кроссплатформенности решена абсолютно полностью

Если вопрос "абсолютно полностью" решён, то почему я не могу запускать программы, написанные на Java, на любом железе?

Ну вангую что у тебя там в корне какие то файлы или пути с кириллическими названиями Винда не сильно любит UTF а темболее mingw

file_get_contents сложновато передавать и получать куки и др заголовки. file_get_contents для POST запроса тоже выглядит многословно, уже наравне с curl. Не очень хорошее поведение при 4xx 5xx ошибках и тд. Хорошей практикой будет использовать file_get_contents только для локальных файлов.

Довольно часто предлагают тестовое задание, на которое у меня нет времени.

В таких ситуациях правильнее будет сказать "Каковы условия оплаты данного задания?". Большинство неадекватов на этом этапе отсеиваются. Просто потому что не только вы что-то делаете для работодателя, но и он вам что-то дает. Если работодатель хочет получить какую-то работу еще до начала трудовых отношений - то следует задуматься, а нужен ли вам такой работодатель? Я просто из исследовательского интереса прошел несколько десятков тестовых заданий и я НИ РАЗУ не получил какого-либо фидбэка. По ощущениям - на результаты тестового никто не смотрит и всем тупо пофиг на него. Поэтому когда мне предлагают тестовое задание - всегда сразу спрашиваю оплату. Никто не хочет платить - это факт, тут ничего не сделать. Почти всегда сразу в отказ идут. Было несколько случаев, когда вроде согласились - но все равно ушли в закат. В целом же, в практике был лишь один случай, когда ко мне пришли и сказали - вот ты умеешь то-то и то, вот тебе тестовое задание, оцени, мы тебе денег сразу заплатим, а там если все пучком - будем работать дальше. И еще несколько случаев, когда работодатели сразу в описании вакансии писали, что тестовое задание оплачивается. Смотреть код тоже почти никому не интересно - такой случай тоже был лишь один, когда я предложил показать код, согласились посмотреть и поспрашивать про него. В абсолютном большинстве остальных случаев, адекватные работодатели сразу говорят: по результатам собеседования нас все устраивает, далее делаем так - вот тут у нас список задач, выбирай одну-две-три простых задачки, если все отлично - работаем дальше, если нет - ну что ж, выдадим зарплату за эти задачки и разбежимся миром. Все остальные, где там сложные и долгие интервью то с одним, то с другим, то задание такое, то сякое - больше на лотерею похоже, когда крутишь барабан и гадаешь - будет сектор приз или сектор ноль.

Разумно ли написать проект с нуля, скажем, интернет магазин, залить все это на гитхаб и давать ссылку работодателям каждый раз когда просят пройти тестовое задание?

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

Разработчики должны иметь свое изолированное окружение, обычно локальное
Дальше неплохо иметь промежуточный dev сервер, как для последнего прогона тестов, так и для интеграционных тестов
Далее dev копируется в продакшн, или снепшот из продакшена копируется в дев и они меняются ( если что можно мгновенно переключиться в старый )
Заливка из VCS только в дев.

Можно ли ставить дев и продакшн в одной среде зависит от того когда тестируется производительность и прочие нагрузочные вещи. Если до заливки в дев, то можно, иначе — нельзя — есть риск завалить тестами или кривыми изменениями.

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

Мне кажется, вы не совсем корректно поняли совет. Нужно было использовать Linux(без иксов) только для запуска докеров, а не перебираться работать в виртуалку.
Ни разу схему выстраивать такую не приходилось, но раз в нативном докере работает, то и так тоже должно завестись.
Можно сетевые карты мака и линухи объединить в бридж, а контейнеры в линухе запускать сеть в режиме Host.
Возможно это излишне и из контейнеров можно ходить на мак по его ip, а не через loclahost. По крайней мере так делает нативный докер

Контейнеры данных

Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять

Нет, npm install надо выполнять ДО сборки образа. Когда контейнер стартует - внутри у него уже все должно быть. Опять же я лично против того, что бы выносить исходники проекта в отдельный контейнер-пустышку. У вас есть контейнер с нодой - исходники для ноды должны быть там. Есть некоторые нюансы связанные со сборкой контейнера но это так.

На файловой системе хоста

Ничего.

Логи прокидываются в stdout/stderr контейнера и собираются на хосте через докер любым подходящим драйвером (читаем документацию).

Конфигурация - все что в конфигах от окружения к окружению меняется - в ENV переменные. Все остальное - не меняется и потому просто вшито внутрь контейнера.

1) в репозитории у Вас получился скорее скелетон, а не пакет фреймворка, у папки шаблонов должно быть осознанное предназначение, нп. приветствующая страница, папка public тоже обычно отсутствует
2) именование интерфейсов как iSomething морально устарело и неправильно по PSR (для классов тоже, там был класс reCaptcha)
3) тесты должны отражать тесты на функционал фреймворка, пока там заглушки
4) непонятен слой Promises, под ним там видно много классов, которые отвечают за разные вещи, стоило бы их структурировать, приставка extreme тоже не отражает предназначение классов
5) странно видеть в core класс рекапчи, это типично клиентская задача и фреймворк не должен ее решать
6) сейчас есть тенденция подключать сторонние orm во фреймворк, потому что проектирование абстракций для базы с нуля это огромная работа