![[The AI Show Episode 142]: ChatGPT’s New Image Generator, Studio Ghibli Craze and Backlash, Gemini 2.5, OpenAI Academy, 4o Updates, Vibe Marketing & xAI Acquires X](https://www.marketingaiinstitute.com/hubfs/ep%20142%20cover.png)
![[FREE EBOOKS] The Kubernetes Bible, The Ultimate Linux Shell Scripting Guide & Four More Best Selling Titles](https://www.javacodegeeks.com/wp-content/uploads/2012/12/jcg-logo.jpg){kind=logo}
![From drop-out to software architect with Jason Lengstorf [Podcast #167]](https://cdn.hashnode.com/res/hashnode/image/upload/v1743796461357/f3d19cd7-e6f5-4d7c-8bfc-eb974bc8da68.png?#)
.png?#)
.jpg?#)
_Christophe_Coat_Alamy.jpg?#)
![Rapidus in Talks With Apple as It Accelerates Toward 2nm Chip Production [Report]](https://www.iclarified.com/images/news/96937/96937/96937-640.jpg)
TypeScript Types Lie & How to Improve Them
The following covers the unique aspects of TypeScript’s gradual typing, and how this can lead to types that are not accurate and can lead to bugs and runtime exceptions. We also cover ways to utilize the gradual feature of TypeScript to improve those types in an iterative fashion. Why Care TypeScript is a language that utilizes strict types and compiles to JavaScript. The point is some developers like utilizing types as they feel the compiler finds issues with their code faster, especially as the code gets extremely large with many devs contributing. They also feel writing types is easier, and requires less code and things to maintain than unit tests. Unit tests are still needed, however, utilizing types can negate the need for many unit tests. Finally, the feedback loop of dynamic languages switches from “write a little code, run it, debug where it breaks, continue” to “write some types, have compiler verify it, run the tests, continue”. Thus the trade offs are as follows. Pros: less code to maintain less unit tests to write more confidence the code will not have runtime exceptions nor null pointers can ensure impossible situations cannot occur by using types to narrow the situation the developer cares about Cons: more overhead in code to read; you have to read the types compiler errors can be just as obtuse or red-herrings like stack traces types, like code, can be hard to understand types are not always accurate That last con is key, and what we’ll be covering in this article. The whole point of investing effort into writing types is that when the program compiles, it works, and there are no surprises. … but TypeScript is gradually typed, so there is gallons of nuance here. Overall TypeScript can be a net positive if you/your team is bought into using types, using the speed of the compiler, and use the types to narrow your problem domain, while your compiler & build setup is easy to maintain and use. I’ve noticed many teams vary in how strict they want to be. I’m suggesting you follow the below as a bare minimum for greenfield / brownfield code bases, else I question why you would use TypeScript and instead just use JavaScript. There are various nuances for projects where you’re migrating from JavaScript to TypeScript. What is “a type lie”? A type lie is when the types specify what a function inputs / returns, but they are either only correct in some circumstances, or just plain wrong. Let’s look at a type truth first. const greet = (name:string):string => `Hello ${name}!` If we pass in a string, we’re going to get back a string. So this is a mostly truthful set of types. Now let’s see what a type lie is. Consider the following code: type Person = { name: string } const parsePeople = (jsonString:string):Array => { return JSON.parse(jsonString) as Array } If you read it the function the types are implying, it says “Pass in a JSON string, we’ll parse it, and give you back an array of People records”. Note I said the word “implying”, not “specifies”. That’s because the above types we’re using are wrong. They are only covering the happy path. If you don’t know any better, like TypeScript, or perhaps you’re just learning, this is not Willful Ignorance. Meaning, you intentionally ignore the unhappy path. Once you learn about the unhappy paths that I’ll show you, however, unless you fix it, you are now being Willfully Ignorant. The happy path would look like this: const people = parsePeople('[ { "name": "Jesse" } ]') However, there are at least 2 unhappy paths the types are not covering. What about parsing a cow? const people = parsePeople('
The following covers the unique aspects of TypeScript’s gradual typing, and how this can lead to types that are not accurate and can lead to bugs and runtime exceptions. We also cover ways to utilize the gradual feature of TypeScript to improve those types in an iterative fashion.
Why Care
TypeScript is a language that utilizes strict types and compiles to JavaScript. The point is some developers like utilizing types as they feel the compiler finds issues with their code faster, especially as the code gets extremely large with many devs contributing. They also feel writing types is easier, and requires less code and things to maintain than unit tests. Unit tests are still needed, however, utilizing types can negate the need for many unit tests. Finally, the feedback loop of dynamic languages switches from “write a little code, run it, debug where it breaks, continue” to “write some types, have compiler verify it, run the tests, continue”.
Thus the trade offs are as follows.
Pros:
- less code to maintain
- less unit tests to write
- more confidence the code will not have runtime exceptions nor null pointers
- can ensure impossible situations cannot occur by using types to narrow the situation the developer cares about
Cons:
- more overhead in code to read; you have to read the types
- compiler errors can be just as obtuse or red-herrings like stack traces
- types, like code, can be hard to understand
- types are not always accurate
That last con is key, and what we’ll be covering in this article. The whole point of investing effort into writing types is that when the program compiles, it works, and there are no surprises.
… but TypeScript is gradually typed, so there is gallons of nuance here.
Overall TypeScript can be a net positive if you/your team is bought into using types, using the speed of the compiler, and use the types to narrow your problem domain, while your compiler & build setup is easy to maintain and use. I’ve noticed many teams vary in how strict they want to be. I’m suggesting you follow the below as a bare minimum for greenfield / brownfield code bases, else I question why you would use TypeScript and instead just use JavaScript. There are various nuances for projects where you’re migrating from JavaScript to TypeScript.
What is “a type lie”?
A type lie is when the types specify what a function inputs / returns, but they are either only correct in some circumstances, or just plain wrong.
Let’s look at a type truth first.
const greet = (name:string):string =>
`Hello ${name}!`
If we pass in a string, we’re going to get back a string. So this is a mostly truthful set of types. Now let’s see what a type lie is.
Consider the following code:
type Person = { name: string }
const parsePeople = (jsonString:string):Array<Person> => {
return JSON.parse(jsonString) as Array<Person>
}
If you read it the function the types are implying, it says “Pass in a JSON string, we’ll parse it, and give you back an array of People records”. Note I said the word “implying”, not “specifies”. That’s because the above types we’re using are wrong. They are only covering the happy path.
If you don’t know any better, like TypeScript, or perhaps you’re just learning, this is not Willful Ignorance. Meaning, you intentionally ignore the unhappy path. Once you learn about the unhappy paths that I’ll show you, however, unless you fix it, you are now being Willfully Ignorant.
The happy path would look like this:
const people = parsePeople('[ { "name": "Jesse" } ]')
However, there are at least 2 unhappy paths the types are not covering. What about parsing a cow?
const people = parsePeople(' 
