Despite working with TypeScript professionally since 2019, I’ve been approaching TypeScript errors with a great deal of trepidation and fear. There’s so much information being returned. Although it’s not as much as Java stack traces in volume, I’ve struggled to make sense of TypeScript error traces and know how to parse them. Whereas most of the time I could resolve most errors with varying amounts of brute force or logic, sometimes a TypeScript error trace can really leave me clueless.
So, this week presented me with a golden opportunity to face some fears and turn trepidation into budding confidence. I was working with the react-select package and some custom components in the codebase. I was making some modifications and I was confronted with the Great Wall of Error.
Something like these…
Instead of freaking out at the Great Wall, I decided to break it down and make sense of it. I need to spend more time on the TypeScript website because the documentation on understanding errors is really excellent.
This part really started to solve the primordial puzzle for me:
“Each error starts with a leading message, sometimes followed by more sub-messages. You can think of each sub-message as answering a “why?” question about the message above it.” (emphasis mine)
If we take the second screenshot as an example, the way to parse the error trace seems to be as follows:
- TypeScript will highlight the offending line with a red squiggly line.
- Top message in the error trace is the leading message. In this case, it’s Type ‘Record<string | number | symbol, string | string[] | Record<string | number | symbol, string>>’ is not assignable to type ‘RecursiveObject<string | number>’.
- Why? Because Index signatures are incompatible.
- Why? Because Type ‘string | string[] | Record<string | number | symbol, string>’ is not assignable to type ‘RecursiveProperty<string | number>’.
And so on.
I’m going to be taking these insights into my work next week and side projects.
So, thank you TypeScript website!
