[Joeri]

I just built a 3500 line chatbot with the ms bot framework in typescript and my experience was very different.

Source maps in node are working fine for me in intellij. I can set breakpoints in the typescript code and step from there with full inspection capabilities.

The library compat issues you're describing I didn't have. I used what MS recommends or uses itself in the bot framework, which is of course all nicely compatible (e.g. mocha/chai/sinon for unit tests). For promises I used regular ES6 promises, so that wasn't an issue either.

[pyrophane]

What you describe would work in dev if you are using your editor's transpiler, but what about production error logging? In my experience that generates JS stack traces and it is a pain to convert those to source-mapped ts stack traces. I know mocha has built-in support for source maps.

Also regarding ES6 Promises. The issue I'm referring to has to do with using 3rd-party libraries that don't provide promise support, which is a lot of popular node libraries. Even if you have type definitions for them, if you use a library to auto-wrap the API to provide promises (which is, as far as I know, still the only way to do it without writing your own Promise wrappers, you lose not only your completions, but also information about the returning types, and the compiler will complain.

I believe most of these problems will resolve in time. I'm sure node will add built-in support for source maps some day, and most libraries will eventually come with Promise APIs.

The problem that will be much more difficult to address is the lack of reliable type information for most libraries. That of course isn't really Typescript's fault, as it just has to do with the fact that most library devs in the node community are writing in JS, but it also strikes me as something that will limit adoption of TS amongst backend developers looking for a static type system.

[Joeri]

Good point about production stack traces. I just now added the source-map-support package to make that issue go away. Thanks for pointing that out.

I did indeed wrap the callbacks into promises myself, so haven't looked into promises libraries, but I can't imagine there isn't an officially sanctioned solution for this.