Изучать JS глубоко и всерьез надо, как и другие языки и технологии. Когда встречаешь вакансию на джуна с "JS + React/Angular + PHP + Django + Mysql и многое другое" - просто закрывай вкладку, они сами не знают, чего хотят)

То, что найти работу без опыта нельзя - это не совсем так. Сложно, но можно. На что у себя в компании смотрим, когда приходят кандидаты во фронтенд: концептуальное знание языка и программирования в целом (своими словами, ну забыл какое-то определение - и фиг с ним, главное, чтобы хотя бы на пальцах рассказал), навыки работы c HTML/CSS/JS и особенно - навыки командной работы, знание Git на достаточном для повседневных задач уровне. Где взять навыки командной работы, если у тебя нет команды? Нужно самому стать командой) Вести пэт-проекты так, как будто на проекте кроме тебя еще два десятка человек, выполнять разные роли. Следить за тем, что и как коммитишь в репозиторий. Если пользовался каким-нибудь трекером - это плюс. Если работал хотя бы с одним фреймворком - тоже плюс. Если можешь показать пэт-проекты, где ты что-то действительно сделал, пусть небольшое, но решающее какую-то задачу - еще один плюс. Бывает, что эти плюсы перебивают опыт работы 5+ лет (хотя там вообще тяжелый случай был))) Потому что опыт - дело наживное, но далеко не каждый обладает способностью обучаться достаточно быстро и непрерывно, набирать это самый опыт и использовать.

Сейчас для многих компаний непростой период, не самое удачное время для поиска работы. Но можно пока прокачивать свои скилы, делать CV, что-то там выкладывать на гитхаб. Попробовать поиграть в "команду" с самим собой. Откликаться на вакансии, пытаться пройти собес. Вот как о тебе узнать, если ты себя не показываешь? Не "открыл hh... и закрыл", а целенаправленно и методично занимаешься поиском. Если откажут в 9 местах - это ок, бывает. В 10-ом могут и взять.

Первое время лучше работать в офисе, будет проще во многом. С опытом можно задуматься об удаленке или фрилансе. Но это у кого как, каждому свое. Не принимай чужие советы (например мои))) на веру, проверяй, эксперементируй, добивайся.

Ну может просто Inverify будет излишним во Vue3?

Суть инверсии управления (Inversion Of Control, IoC) заключается в том, что класс передает контроль (читай: ответственность) за создание зависимых экземпляров, которые нужны классу, контейнеру, который вместо этого предоставит им эти экземпляры. Одной из реализаций инверсии управления в применении к управлению зависимостями является внедрение зависимостей (Dependency Injection, DI). Inverify реализует инверсию управления и, из того, что я видел и трогал, изредка использовался с Vue2 через Class API (который реализуется сторонними библиотеками). Там использование подобного подхода оправдано тем, что с инкапсуляцией частей логики, шарингом кода и менеджментом состояний все непросто, так как нехватает адекватных механизмов для этого. Эти проблемы в свое время привели к старту разработки принципиально нового фреймворка под названием... Vue3) В процессе рассматривали Class API и Composition API, Composition API победил и вошел в релиз, а Option API достался нам по историческим причинам (ну нельзя так просто взять и заявить, что половину опыта разработчикам стоит выкинуть в мусорное ведро).

Итак, у нас есть Vue3 и Composition API. Без классов. Только setup-функция и useЧтоТоТам кусочки логики. Что мы имеем с этого? Мы можем вынести определенную часть логики в use-функцию. Внутри use-функции может происходить что угодно - мы импортируем только результат в виде ref-ов и функций (назовем их actions-функции). То есть use-функция отвечает за создание зависимых экземпляров, которые нужны компоненту, то есть выполняет функцию DI. Также use-функция может использовать другие use-функции. Все это значительно расширяет возможности декомпозиции, повторного использования кода, и уменьшает зацепление, для чего Inverify и предназначается. Пожалуй, единственный кейс, который мне с ходу удалось придумать для использования Inverify с Vue3 - это когда мы знаем, что будем использовать нашу логику в различных приложениях и средах с различными библиотеками рендеринга (Vue3, React, и т.п.). Но для каждого приложения в отдельности это будет дороже, поэтому стоит дважды подумать, стоит ли игра свеч и нет ли более простых путей.

Что касается стейт-менеджмента, то Composition API тут тоже самодостаточен, когда приложение небольшое и рендерится на клиенте. Достаточно использовать замыкание и глобальный стейт готов. Pinia помогает с SSR и отображением состояния в дев-тулзах, библиотека удобна для более крупных проектов. При написании сторов внутри все пишется точно так же, как если бы использовался голый Composition API, да и в приложении используется практически так же (за исключением использования нескольких встроенных методов). Поэтому простенькое MVP-приложение очень просто перевести со сторов на use-функциях на использование Pinia. Vuex сейчас смысла особого использовать не вижу, теряется удобство и консистентность использования.

В разговоре о DI нельзя также не упомянуть https://vuejs.org/guide/components/provide-inject.html. Его можно использовать при разработке декларативных библиотек компонентов, но это такая штука, которая может неочевидно выстрелить в ногу, использовать следует с осторожностью.

Итого, на мой взгляд, использование Inverify с Vue3 избыточно и усложняет написание кода. Грамотное использование Composition API, Pinia (при необходимости), декларирование интерфейсов (если используется TS) и соблюдение принципа инверсии зависимостей решает все эти проблемы.