I'm absolutely fine with external libs not being typechecked if there's no d.ts. The issue is it literally didn't support this scenario until 1.8 (when AllowJS was added). To me, this is the biggest tell that there's something fundamentally wrong with TS's design priorities. How could it not support JavaScript libraries for so long?
There are equivalent reports on GitHub and elsewhere on the net, as well as numerous related but separate issues.
IDEs from the same organization that sponsors TS don't even work reliably with it. Note one of the responses: "try VSCode." Indeed, VSCode works for me on the exact same code.
Currently I'm doing the same thing as you: running the TS output + the non-TS codebase through a giant blender of browserify + babel.
At one point, I would use --outfile, which makes TSC bundle all your files and dependencies. Neat, right? Nope - it gets the order of the dependencies wrong, which you find out later, at runtime. The maintainers on GitHub said "don't use outfile."
Are you really sure it wasn't possible to use external libs prior to the allowJs flag? I vividly remember a colleague fiddling around with TS when 1.0 was released, and we had discussions about definition files and how lacking they were. But I'm pretty sure he was able to declare an external module as "any" in a d.ts file, and then he could simply require it and use it without type information. As far as I know, the allowJs flag allows you to import/require your own .js files (as opposed to external modules), before that this wasn't possible apparently. Without this functionality I don't know how it was possible to gradually convert a code base to ts. We probably wouldn't be using TS now without the allowJs flag. I guess we are lucky to have picked up TS in a state where most of the early issues have been resolved (not saying there are no issues left).
I totally understand your frustrations with VS, though most of the problems you mentioned seem to be related to the TS integration in VS, and not with TS directly. But issues like yours are the reason why I lost hope in VS. I try to use it as little as possible.
I'm not sure if it was impossible, just that it was a giant mess and it utterly failed to work properly for me. Broadly speaking, point is just that TS treats JS as a second class citizen, and it adversely affects the day to day usability.
Here is one of numerous posts mirroring one of the module resolution issues that has plagued my project: https://stackoverflow.com/questions/39957100/visual-studio-2...
There are equivalent reports on GitHub and elsewhere on the net, as well as numerous related but separate issues.
IDEs from the same organization that sponsors TS don't even work reliably with it. Note one of the responses: "try VSCode." Indeed, VSCode works for me on the exact same code.
Currently I'm doing the same thing as you: running the TS output + the non-TS codebase through a giant blender of browserify + babel.
At one point, I would use --outfile, which makes TSC bundle all your files and dependencies. Neat, right? Nope - it gets the order of the dependencies wrong, which you find out later, at runtime. The maintainers on GitHub said "don't use outfile."