Nevertheless, I do think there are some conditions that could make TypeScript less valuable for a particular project or team. In this article, I’m going to talk about the things you ought to consider when weighing whether or not to add TypeScript to your project.
1. Greenfield vs. Brownfield
To give you an idea of how much time this has saved me on my current project, I’ll tell you this: I haven’t had to invest time in configuring a watch because I just don’t find myself chasing down
[object Object] errors or
undefined is not a function run-time errors enough to merit the investment.
If you’re working on a brownfield project, the decision becomes a little tougher. TypeScript would be helpful for new code that you’re writing, and adding it incrementally might cause a headache if you’re digging into code that isn’t typed.
Consider that your module relies on an object that another module produces with lots of properties and nested objects. Step one would be to type that object, but then you have to decide to either cast what that module gives you or type all of the functions and references in the other module. That module may have dependencies in your codebase, so then you’re faced with making the same decision again. And while casts are convenient, they can lie, too, which leads to types in your codebase that you can’t trust, which circumscribes the whole reason TypeScript is great.
2. Uniform, Idiomatic Adoption
Although TypeScript does a very good job of emulating a strong typing system like you’d get in Java, the user is the weakest link since there are always opportunities to add the wrong type or no type.
any, which would be a really frustrating experience: not knowing when to trust the TypeScript compiler.
I’ve found it really helpful to have a TS expert who takes to heart our teach and learn value during code review. Another helpful mechanism is to invest some time in configuring TSLint as well as a picking out helpful tsconfig compiler options like
Bottom line: TypeScript isn’t worth the price of admission if you don’t know when you can count on TypeScript’s compiler to yell at you about errors that you or someone from your team hid from it.
3. Toolchain Fit
To keep TypeScript from becoming a PITA in the management of your project, you need to make sure of two things:
- Your toolchain for building/packaging/running/watching your web app is 100% seamless. There’s lots of community support for TypeScript compilation with tools like Grunt, gulp, and webpack, but it can be a little futzy when it comes down to utilizing these tools with advanced TS features like multiple
4. Server Language
If you’re writing a Node server, this is basically a no-brainer; you have even more of an incentive to adopt TypeScript. Very likely, a lot of the types you create on the back end will be extremely useful when it’s time to present them on the front end.
Not only that, but seriously, if you’re writing a Node server, there are few places where static analysis is more helpful than in dealing with complex business logic that ought to be captured on the server.
5. Integration with Frameworks and Third-party Libraries
A possible risk occurs if you rely on a library that doesn’t provide good type definitions or hasn’t had someone in the community publish some through Definitely Typed. An example is the Lodash (I love Lodash)
Though it’s possible to type
chain, if you are a heavy user of third-party libraries, you may need to spend some time investigating what kind of TypeScript support is out there or what kind of investment it would be to create (and maintain) type definitions.