TypeScript has joined the ranks of the most popular programming languages. This is great news for TypeScript developers. More companies are going use TypeScript in their projects and their skills are going to be useful for the foreseeable future.
Companies now are in a weird position. There is a business case to convert existing code to TypeScript. Not only would you get the benefits of TypeScript but you now also make the company more attractive for new developers.
The solution to this simple - the codebase has to be migrated to actual real TypeScript. In order to get there you need to do two things:
Ensure that all developers learn and write TypeScript.
I imagine that a lot of conversations with managers go something like this:
Developer: I want to use TypeScript, I have heard only good things about it.
Manager: How much effort will this take?
Developer: Not much.
Add the typescript compiler
Add types over time
Unfortunately this sets the wrong expectations for the manager. He will only allocate a small amount of time for this ‘TypeScript’ thing. The discussion should not be about the minimal steps, but what is the ROI (Return on Invest).
Before you go to your manager you should be clear what you want to communicate to your manager. Do not expect that your manager knows what TypeScript is, you are going to have to educate him and you will have to sell him the idea and he has to buy into the idea.
The best way to convince a manager is to explain him the situation. This can be done by presenting good reasons and a plan how to execute it. This makes it easier for the manager to decide if it should be done and prepare resources to be allocated to this task.
The conversation should be more like this: Developer: I want to use TypeScript. There is a high business value in converting our existing codebase.
Manager: Interesting. How much effort will this take?
Developer: Unclear. We can start immediately implementing the minimal steps. After that we will have a clearer picture to know how much effort it is going to be. Most likely we can convert gradually over the next couple of months our entire codebase as we implement new features.
Manager: Multiple Months? We can’t do that.
Developer: Here are a couple of reasons we definitely should do it
Reasons to convert to TypeScript
Finding Obscure bugs
Just by adding types to the code will most likely reveal several existing bugs in the codebase. This in it self already has an incredible business value.
The customer gets a better product. As the product now less bugs and an overall better quality.
The development team has to spend less time on debugging errors, as they know exactly where they are. Thus the team is available to develop more features.
The support team has less volume of complaints.
Unfortunately the developers will need additional time to fix these new found bugs. This will prolong the time needed to migrate to TypeScript.
Important: I made the mistake of not communicating this early with my manager, and we then had to have several discussions about TypeScript introducing new bugs, while in reality TypeScript just revealed existing bugs.
Write new code with typo
Execute code in Browser
do steps to execute your newly written code.
Discover you have a silly typo
Search for the location of the typo
Write new code with typo
Code does not compile. Error message tells you in which file and line to look for error.
Even if you are not convinced. Just think about the last time you had to meet a deadline and you were running low on time. My guess is you would be happy for every shortcut you can get.
TypeScript will increase the development velocity, reduce common errors and increase the confidence that the change to the code will actually work.
Obviously if the developers can work a faster is a great business value.
Earlier Error Detection
During development - if you adjust a function signature, with TypeScript the code will not compiled if this change accidentally broke some other part of the code. Making it very easy to immediately adapt the change - without accidentally introducing a new bug to the system.
Less errors in the codebase is going to be better for the product, thus improving the overall quality and at the same time ensuring that existing functionality still works. Reduces a lot of costs down the line, debugging costs, error removal, support costs etc.
Decrease Onboarding Time
New Developers will have it easier to read and understand the code. A new developer will be able to contribute to the project faster.
Equally this is true for developers that are consuming your code as a library. It makes the library much more comfortable to work with.
In my experience managers do not see a lot of business value in this, because it is so rare that a new team member has to be onboarded. (No matter how high the actual team fluctuation is.)
Encourage Developers to write TypeScript
Developers that started to learn programming with a strongly typed language usually do not have any difficulties to adapt to TypeScript.
Unfortunately developers that learned to program in a dynamically typed language find it quite difficult to work with types. They need additional training to work with TypeScript effectively. I would recommend to read the TypeScript Handbook and taking a free official course from Microsoft Learn.
In practice developers do not have the time to actually do the training. What happens then is that developers tend to get frustrated with the TypeScript compiler errors and then take the shortcut to disable the warning message by either using the ‘any’-keyword or the //@ts-ignore
To avoid these bad practices, you have to define coding guidelines and enforce them with a linter like ESLint.
What is the any-keyword?
From the TypeScript Handbook - “TypeScript also has a special type, any
, that you can use whenever you don’t want a particular value to cause typechecking errors.” - It continues in the Do’s and Don’ts: ”Don’t use any
The key point is, there is a valid use-case for this keyword, the important thing is that this is only suppose to be temporary. As this is part of the language itself, you cannot simply disable the usage of the keyword.
Using ESLint to disable the TypeChecking Suppression
Add EsLint to your project
npm i -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser
Important: If you do not want to use the rules from @typescript-eslint/recommended
, you should additionally ban the usage of the //@ts-ignore
-comment. This comment also allows you to suppress TypeScript errors. Add following rule to your ESLint configuration: "@typescript-eslint/ban-ts-comment": "error"
If you end up with too many errors to fix, you can reduce the sensitivity to ‘warning’. Then fix the code over a longer period of time and when you hit zero warnings, increase the severity back to ‘error’.
Ensure that every developer uses ESLint
The easiest way is to set up a git pre-commit hook, that always executes ESLint. The developer then cannot commit code that does not pass the linter. You can find a full guide how to set this up with the help of husky.js here.