It is easy to see why the tooling is good - you can check out for yourself in the interactive environment on the TypeScript website. I used it through VisualStudio and though I found it glitchy in a few places, with having to restart VS a dozen times, it is overall quite helpful.
My complaints are mostly on what I consider to be poor language design decisions.
First, the type system does not even try to be sound:
Fourth, there is no abstraction. I have not found a way to define an abstract type. Interfaces are always open. Classes are open too, and I have not found how to make all constructors private. This is really annoying.
Fifth, there is a lot of recursion craziness going on in the language, complicated with structural typing. I think the types are best described by regular trees. This is not exactly implementation-friendly - I had a very hard time trying to implement things like a subtyping decision procedure, especially since the language spec is very terse on these issues. The online TS compiler works for quite arcane examples - I wonder if they have a correct equality and subsumption implementation over regular trees, or they are using some hack that just happened to work on my examples. Not that it matters very much since subtyping as defined breaks soundness and is therefore not very interesting or useful.
- A machine-readable simple (JSON-based?) standard spec for API contracts
- Tooling for generating easy to use API documentation from the contracts
- A utility for sealing a value with a contract to introduce runtime checks and blame assignment (there is some good literature on how to do that)
- Tooling for generating `.d.ts` from contracts, parsing `.d.ts` into contracts (possibly with some approximation)
The problem, as always, is marketing - convincing library authors to use a formalism to express their API. Even if we had a working system satisfying the above wishlist, this would be a tough one.