[pyrophane]

I built a non-trivial webapp in nodejs + Typescript but abandoned it due to these issues:

1. You can generate source maps for your TS files, but node can't use them. There is some support for source maps via the node-source-map-support, but it doesn't play well with a lot of stuff out of the box. Just getting accurate stack traces in my logs turned into a project of its own.

2. Most node libraries don't include type definitions, and what is on DefinitelyTyped is more likely than not to be out-of-date and inaccurate. Having the wrong type definitions might be worse than none at all, which means for the most part you'll be declaring a lot of stuff as "any." It makes even preserving the types in your own code difficult, as anything that touches a 3rd-party library is going to come back as the any type without additional annotation.

3. Similar to 2, if you want to use a promise-based approach to deal with the "callback hell" induced by node's continuation passing style, you are probably going to need to use a library that does runtime mutation of the many libraries that don't support promises, which means that any time information you do have about 3rd-party libraries is going to get lost.

4. The last two items, combined with the lack of runtime type checking, means that your types are going to be difficult to maintain and can easily become inaccurate without feedback from the compiler to let you know that something is wrong.

[jsynowiec]

Re 1: This is not a problem with TypeScript, but with Node. It's the same with every to-js-transpiled language. You can use https://github.com/evanw/node-source-map-support to get stack traces for your TS sources.

Re 2: I do agree that this is a problem but remember that it's all just a community effort. You can always create your own type definitions or enhance existing ones and share on the DefinitelyTyped repository. Also, most of the time if a type definition is out of date or invalid, you can just create your own partial typedef for a module with only those several methods you are actually using.

Re 3: IMO it's a feature. By using, for e.g. a bluebird library to wrap third party code in a Promise, you are changing the way how your code is interacting with that library by redeclaring the whole library or some parts of it. TSC is complaining because you've changed the declarations. You have to provide your own type definitions, either inline, or for the whole module.

I've engineered or reviewed several projects that are using TypeScript with success. The teams after initial hiccups are mostly not willing to come back to pure JavaScript now.

I'm not advocating to use TS everywhere and for every project. It all depends. Many factors must be considered but some sort of type checking is usually a good thing to have.

[pyrophane]

Yea, I didn't really mean for my comment to be a criticism of Typescript itself, but rather I wanted to explain some of the difficulties I have encountered trying to use it on a large node project.

Per your follow-up comments:

1. Have you gotten node-source-map-support to work with a logging framework like Winston that handles uncaught exceptions? It didn't work out of the box for me, but I'm sure that with some effort it could be made to work.

2. Yea. I think a big part of the problem is that even a lot of very popular node libraries just aren't that stable. APIs change a lot and the documentation is poor, so keeping a type definition up-to-date and accurate is particularly difficult.

3. I agree that that is by design, but that doesn't make it any less of a barrier to using promises across an application that depends on a lot of 3rd party libraries, and as a developer I don't want to have to spend a lot of my time maintaining type definitions to work around it in my project.

I agree that having used Typescript I would not want to move back to plain JS, but for me the experience pushed me away from using node as a backend in the future, as I think there are other platforms that provide the same benefits without the drawbacks and difficulties.

[bengalister]

I am just curious, which platforms do you think provide the same benefits without the drawbacks ?

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

[lucideer]

I've run into the same problems with #2 quite a lot, especially in terms of libraries that are on DefinitelyTyped but are either out-of-date, or where the DefinitelyTyped typings are in some way tailored toward a specific module loader choice (node/SystemJS/es6/&c.).

In the end, my solution has been to just use only the DefinitelyTyped typings that work well, and fall back to inserting my own broad, liberal `declare`s for remaining libraries. This has the enormous drawback of effectively opting out of most of the benefits of using TypeScript in the context of those specific libraries, but it seems like a worthwhile trade-off given I keep the benefits throughout a lot of the app.

I haven't encountered #1 personally - this seems to work OK in my experience.

On #3, I've always thought both that "callback hell" was exaggerated and largely called by badly planned code rather than being a fundamental problem with callbacks, and also that Promises are an oversold solution that offer some benefits but are certainly no magic bullet. My code generally uses Promises, but never pervasively. They wouldn't be a dealbreaker by any means.

TL;DR while your criticisms are understandable and valid, they seem relatively minor based on my own experience. Abandoning an app completely seems extreme.