HabrDI в TypeScript без декораторов: почему это будущее
Каждый, кто пишет на TypeScript хотя бы пару лет, отлично знаком со стандартным DI-сценарием: класс, декоратор @Injectable() , флаг emitDecoratorMetadata в конфиге и рантайм-магия фреймворка. Этот подход казался прорывным в 2015 году, но современный TypeScript ушел далеко вперед. У нас появились мощнейший статический анализ и продвинутый вывод типов, в то время как популярные DI-контейнеры вроде NestJS, InversifyJS или TSyringe будто законсервировались в прошлом. Слепая приверженность старым паттернам начинает откровенно тормозить индустрию. Из-за legacy-декораторов мы оказываемся заперты в рамках медленного tsc без возможности безболезненно уйти на сверхбыстрые сборщики вроде esbuild или SWC. Наша бизнес-логика намертво заражается инфраструктурными импортами сторонних библиотек, а ошибки в графе зависимостей и скрытые утечки памяти обнаруживаются не на этапе компиляции, а уже в рантайме под нагрузкой на проде. Но что, если заставить компилятор TypeScript проверять валидность всего графа зависимостей еще до запуска кода? Без декораторов, reflect-metadata , кастомных трансформеров и тяжелой кодогенерации. В этой статье мы разберем концепцию «экстремальной типизации» на примере InferDI — первого DI-контейнера, где сам граф зависимостей вместе с lifetime-правилами перенесен напрямую в систему типов. Мы поговорим о фундаментальных вещах: почему полный отказ от «удобной» магии аннотаций в пользу 100% ванильного TypeScript — это лучшая инвестиция в архитектуру, безопасность, скорость сборки и долговечность вашего проекта на годы вперед.
https://habr.com/ru/articles/1042290/
#typescript #dependency_injection #dicontainer #reflectmetadata #внедрение_зависимостей #inversifyjs #tsyringe #awilix #Typed_Inject #inferdi
Taida