[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.