At the time we were tracking closely with all the changes, sometimes even running with the nightly builds to get that one more feature we needed. Honestly, it’s probably the closest to the bleeding edge I’ve ever been, and sometimes we did get cut a little.
During my work on that team, tracked along changes from 1.6 to 1.7, and on to 1.8. We even worked with some of the preview builds for 2.0.
Not For Small Projects?
During that time, it was my opinion that TypeScript was great for larger projects, like your company’s main product. I found that pre-2.0, it was very cumbersome to set up new TypeScript projects. Especially with NodeJS.
When I found myself making a quick one-off scripts for a proof-of-concept or a small sub-project, I would avoid using TypeScript unless the scale of the project was worth the setup overhead.
What made setup so bad?
Build Script Setup
This one’s not entirely solved today, but it’s improve a lot. Setting up your build scripts was not always easy. For example, when we were depending on TypeScript 1.8 features, a lot of the supporting tooling like grunt and gulp build tasks would have hard dependencies on version 1.6. TypeScript was moving very fast, and not everyone was so invested as to provide tooling support for the latest versions.
Some tooling provided good support for loading settings from tsconfig.json, others ignored it. This became an issue for the split versioning I mentioned earlier. Some tooling did not support new build options I was using, even when I forced them to use the correct typescript version.
Debugging support wasn’t always great either. Post-processing tools like UglifyJS didn’t always have good support for input source-maps, if they had support for source maps at all.
To provide mappings for stack traces in node, source-map-support needed to be loaded as one of the first things in the application. This was just yet another dependency when starting a new project.
TypeScript in a vacuum would provide a marginal benefit for a small project, especially with language support engines like Salsa that give much of the same experience without inline type annotations. In fact, even TypeScript itself can understand JSDoc comments, so there’s no need to go all in with TypeScript if you don’t want.
Where TypeScript really shines is when you include the type definitions for libraries you consume.
In the pre-2.0 days, it managing type definitions was a pain. There was a huge community of developers contributing definitions to [DefinitelyTyped], but because they were third-party contributions they were not always up-to-date, and being manually assembled there was often quite a lot of style difference from one contributor to another.
Ultimately, in my opinion, the TypeScript language project itself solved the definition publishing problem in the most elegant ways.
Today, the only tools I use to import types in npm. To install the type definitions to NodeJS, all I need is:
npm install --save-dev @types/node
Looking for types for momentjs?
npm install --save-dev @types/moment
It’s that simpe. This works because TypeScript 2.x added support for some really good default lookup locations for types. No more wiring up references with triple-slash comments and xml tags.
giving TypeScript a more direct hint to where to find the typings without downloading
any additional packages or files.
So I Changed My Mind
So, I’ve changed my tune. Now I love TypeScript for everything. This is definitely a case of good design, and developers breaking down barriers to use. For me, new TypeScript project setup time has gone from over a day (and that’s for my 3rd and 4th projects), to about 15 minutes.
So if anyone asks me if TypeScript is worth the effort, I’d simply say “yes”. No more caveats.