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

Ох, так я себе это и представляю, как люди по кругу пуляют ветки друг друга

если у вас стрикт мод, то ничего нигде не поломается. для локальных переменных тип нужен очень редко

и что в этом плохого?

не понимаешь из гитлаба/хаба - смотришь локально

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

время разработки увеличивается

спулить ветку это 10секунд делов)

если вы перешли на ревью вы же не разрабатываете пока ревьювите

спулить, собрать или натравить vs code 🙂 потом обратно вернуться в дифф и проделжать искать такие computed переменные) да, прям 10 секунд

нужен пример конкретнее

а заставлять людей писать борщ борщ = нью борщ это норм)

я даже не знаю, что может быть конкретнее. ну вот импортируешь ты функцию из другого модуля (файла), а переменной тип не указал, ожидая, что там

number

, завтра эту функцию переписали и она стала отдавать

string

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

number

string

для template string почти всегда все будет ок, в других случаях на несовместимом типе ТС упадет. Их достаточно писать только для аргументов функций\методов, возвращаемого типа и полей классов. Тогда у вас будут барьеры где будет валидация и падения компиляции в случае ошибки

У нас в команде больше 10 человек и проект на наксте, и мне кажется, что даже 5 человек - это уже много, просто код успевает так быстро меняться из-за структуры проекта, что где-то остаются неиспользуемые модули стора при замене их на новые, где-то наоборот, остаются ссылки на старые модули, хотя их уже нет и в рантайме получаем ошибку. Сама идея централизованного vuex мне видится ошибкой, но, к сожалению, во vuex4 ничего не поменяли, а

posva/pinia

прототип.

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

Ну и vue3 с его валидацией пропсов пока еще недостаточно хорош. Как пример, валидация с union будет приводиться к вмещающим типам, например

1 | ‘hello’

будет

[Number, String]

. Свелт на

validate

скажет ошибку. Да и вообще, сама идея с

setup="props"

кажется каким-то костылем.

Про реакт с его плагинами для eslint, которые сами расставляют список зависимостей даже говорить не хочется.

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

Я работаю с реактом на ТСе в продукте над которым работают одновременно гораздо больше 10 человек. Про плагины для eslint я не понимаю даже о чем речь. Может у вас что-то просто неправильно настроено. С вуем я не работал, но слышал что поддержка ТСа там в принципе не торт.

плагины для хуков для расстановки зависимостей на разные use<Name>.

Вы какой стор пользуете?

Редакс, но он не централизован и не везде нужен. Сложная история.