Комментарии 5
Вы знаете, а я вот наоборот вынужден был дойти до TS, потому что анализ Storm,Idea/etc JS кода оставляет желать лучшего, но что одно что другое вгоняет меня в ступор. И в том числе изза того что вы указали. Но ТС со своим контрактами уровня "мамой клянусь" и странными практиками (а давайте везде весело ставить нулы) и без нормального рантайм функционала типо полноценной рефлексии вызывает у меня ощущения, что за 20 лет в JS мире не изменилось вообще ничего.
Без JSDoc'ов анализ JS-кода вообще очень печален в любой IDE. А с JSDoc'ами анализатор IDEA очень даже неплохо с кодом управлялся. Может и похуже Java/JavaDoc, но точно не хуже, чем PHP/PhpDoc.
Без них я вообще не знаю как люди живут. И все же похуже Java/Php: постоянно недоумеваю почему в js файлах у меня нет предупреждения о том что свойства такого у объекта просто нет, иногда просто тип не распознается, некоторые хинты по месту тупо не работают через раз. Я последние полгода живу буквально с ними в обнимку, наелся)
Т.е. основная проблема в том что вы используете DI, но не понимаете как как подружить с ним typescript, который по своей сути является совокупностью JSDocs и транспилятора babel (это отсылка к религиозным соображениям, не в обиду :) )
Во vue.js, например, есть механизмы позволяющие выполнять инъекции кода в экземпляр для работы в рантайме и там же есть возможность выполнить инъекцию в исходный интерфейс для того чтобы тот же language server в vscode отработал корректно (и в других редакторах или ide тоже)
Работает это все через декларирование глобальных типов/модулей и их перегрузку, если это можно так назвать
Возможно это то что вы ищите
Не совсем так. Я использую DI через конструкторы в чистом JS. Без транспиляции вообще. Дело не в TS, а в транспиляции (любой). Если (когда) EcmaScript по своему синтаксису приблизится вплотную к TypeScript - я спокойно буду указывать типы в сигнатурах функций. Я так уже делал - в PHP. Там до версии 5 было всё то же самое, что в JS сейчас.
Но я когда-то писал код на Java под GWT и транспилировал его в JavaScript. Тогда-то ко мне и пришло осознание, что когда мы транспилируем один язык в другой, то их недостатки суммируются, а достоинства - нет. Так что тут дело не в синтаксисе TypeScript, а в транспиляции как таковой.
У меня довольно неплохо работал JSDoc в PhpStorm. Как оказалось, это PhpStorm довольно неплохо работал с JSDoc :) Я использовал и автодополнение, и навигацию по коду, и документирование во всплывающих подсказках. В общем всё, что мне давала типизация в PHP/Java. Но этот же самый код переставал обслуживаться "в самой популярной IDE для JS-мира". И это озадачивало.
Ответ, на мой взгляд, в том, что Microsoft не будет развивать один свой продукт (VSCode) в ущерб другому своему продукту (TypeScript). Не будет нативной поддержки JSDoc в VSCode от Microsoft. Даже если код написан на чистом JS, всё равно нужен файл jsconfig.json и запись "types": "types.d.ts" в package.json, если проект планируется использовать с VSCode (или с любым другим редактором кода с возможностью интеграции c tsserver по LSP). Если будет "другой хороший JSDoc-анализатор" с возможностью подключения по LSP, то у него будут свои правила (свой "jsconfig.json").
Ну а пока, да - придётся декларировать всё мало-мальски значимое в types.d.ts , чтобы tsserver мог это видеть.

JSDocs в VSCode