Robur

Это решение не нарушает типизацию, а наоборот - вы точно знаете что в этом случае в T будет именно number и поэтому `return this._numberStep(value)` полностью валидно. А вот компилятор не знает, и вы ему таким образом даете подсказку.
Конечно лучше если он сам смог вы сузить T до number в этом случае, но тут придется немного помочь.

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

Пишите as и спите спокойно.

доки, которые говорят сами за себя:

The GraphQLModule is nothing more than a wrapper around the Apollo server.

Скорее вопрос - можете ли вы _не_ использовать apollo в nest, но кому это нужно.

1) решается по разному, в идеале - все созданные ивенты немутабельные и лежат в базе вечно. Это позволяет избежать кучи проблем. То есть при изменении надо создавать event v2. Но - это только на несовместимые изменение, добавление поля обычно можно сделать совместимым. Код который будет работать с этим полем будет работать должен учитывать что description может быть а может и нет. Старый код который работал без description - будет работать как работал и останется без изменений.

Чаще всего достаточно добавить новые ивенты для новых вещей. Например раньше были аггрегаты без description, теперь появилось это поле, это значит что появились какие-то операции над этим полем и вы можете добавить ивент DescriptionAdded вместо того чтобы менять event создания.
Однако я встречал статьи о том что люди переписывали историю ивентов для поддержки нового формата - возможно в каких-то случаях это действительно более оптимально. Не делал, подводных камней не знаю.

2) создавать "исправляющие" ивенты. например ваш баг добавил всем к дню рождения лишний день при создании пользователей - создаете еще ивенты которые отнимают этот день.

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

например храните в SQL список todo на текущий момент, со всеми ивентами и просто делаете select * from todo.
ну или хотя бы делаете таблицу со всеми create ивентами чтобы читать не 50 миллионов и фильтровать а сразу получить список аггрегатов одним запросом.
Тут eventual consisntency встает в полный рост.

Я все починил, теперь ваша карьера и ориентация в порядке!
Не благодарите.

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

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

Несколько вопросов на которые стоит ответить
1. С другими людьми в команде он так же себя ведет? Они так же мучаются и от них он свой идеальный код тоже защищает?
2. Вы действительно уверены что ваша обида на критику не мешает вам оценивать ситуацию адекватно? Человек может с кислым лицом или резкими фразами говорить вам правильные вещи, а вы реагируете в первую очередь на подачу - это бывает куда чаще чем кажется.
3. Что он сам говорит по поводу причин почему так делает?

Тут вариантов два - либо принять ситуацию либо менять.
Менять можно разными путями - поговорить с ним тет а тет - сказать что так и так иваныч, я тебя считаю за крутейшего профи, и многому хочу у тебя научиться, но мне сложно воспринимать информацию в такой грубой форме. Я вот хочу в твоей команде вырасти профессионально чтобы потом без тени сомнения говорить "а вот там я работала с крутыми чуваками и столькому научилась что до сих пор вспоминаю с гордостью". А ты хочешь чтобы это произошло? - если скажет да - решайте как это сделать, может выйдет может нет но первый шаг хороший, если скажет что нет - делайте выводы и решайте что делать дальше.
Второе - можно пойти к начальству которое принимает решения о переводе из команды в команду и рассказать все как на духу - такая то проблема, это сильно сказывается на твоей работе, хочу в другую тиму, там буду работать эффективнее и развиваться быстрее.
Адекватное начальство будет только за то чтобы работники работали лучше, конфликтов было меньше и люди не выгорали. Для фирмы это прямые потери в деньгах и в продукте.

У вас в json - не массив, поэтому все и падает.
как исправить - либо переделать на массив, либо менять логику чтобы умела работать с тем что вы в json положили

если прямо такая - то можно и без регулярок
const num = parseInt(str.replace('Товаров ',''))

Интенсивной работы в день 5-6 часов максимум. Больше - только на ограниченное время, с обязательной компенсацией отдыхом. В офисе 9-18 работают в целом так же, кулер, поболтать, что-то обсудить 10 раз в день, почитать статьи. По моим личным ощущениям на удаленке работа интенсивнее, даже с учетом меньшего количества часов. Поэтому работаю по часам и на ставке больше чем в офисе на 8 часовом рабочем дне.
Пробовал помодоро - не зашло.
Бывает что накапливается и какие-то дни работа вообще не идет - даю себе отдохнуть, могу поработать часа два-три.
Что-то новое изучаю иногда в формате перерывов - поработал - почитал. Так как график и учет времени гибкий, это не считается рабочим временем, и совесть не мучает. Могу посередине дня отдохнуть пару часов если совсем не идет, или сходить прогуляться или еще что.
Свои проекты сначала пилил "по вечерам и выходным", особенно когда работал 9-18 потом понял что так не пойдет, на долгий срок это провальный подход, поэтому сейчас больше работаю как часть рабочего времени. Уменьшаю основную работу (при этом естественно уменьшается доход).

Самое главное - правильно оценить свои силы и исходя из этого решать сколько куда их потратить. Может у вас сил хватит и на работу и на проекты и на хобби и еще перед сном почитать - без проблем, делайте все это. А если их не хватает даже на 8 часовой рабочий день - стоит это признать и не пытаться себя нагрузить сверх меры, получите новый срыв. Или отказаться от чего-то или искать другие способы кроме как "работать больше". Тут главное быть честным с собой и не "добавлять себе очки".

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

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

Все что касается того чего можно и чего нельзя - https://themeforest.net/legal/author

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