Ну может просто 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) и соблюдение принципа инверсии зависимостей решает все эти проблемы.
