We recently enabled "noImplicitAny"
in a relatively old TypeScript project. It resulted in 269 new errors. Most of those were missing type annotations but in a few cases, we found problems with the code. These had been around for months and were not caught by our test suite.
TL;DR;
We should prefer strict TypeScript configurations to catch issues, not just at compile-time, but (with a good IDE) as we type.
We should try to keep up-to-date with TypeScript versions to benefit from the ever-improving error messages; saving development time.
The case of the message id
We had an object specifying one message for each key. This was working before "noImplicitAny", but now we get an error:
const id = getMessageIdFromSomeObscureLogic();
const messages = {
success: "Everything is awesome!",
warning: "Something is not entirely correct.",
error: "An error was found. We can' go on.",
bananas: "Do you like bananas?",
example: "I'm running out of ideas for examples.",
typescript: "Something to do with TypeScript",
javascript: "Something to do with JavaScript"
};
const message = messages[id]; // ERROR! (see below)
}
The TS error reads:
Element implicitly has an 'any' type because type '{ success: string; warning: string; error: string; example: string; typescript: string; javascrip...' has no index signature.
The problem here is that the keys of the messages
object must be either 'success' or 'warning' or 'error' or 'example', etc. It can't just be "any string".
We can fix this in a few ways:
Index signature "fix"
The error message mentions "index signature". We can explicitly expand the type declaration to accept any strings as keys, like this:
const messages: {[index: string]: string} = {
success: "Everything is awesome!",
warning: "Something is not entirely correct.",
error: "An error was found. We can' go on.",
bananas: "Do you like bananas?",
example: "I'm running out of ideas for examples.",
typescript: "Something to do with TypeScript",
javascript: "Something to do with JavaScript"
};
const message = messages[id]; // no error
Type-casting "fix"
We can turn the "implicit any" into an "explicit any" like this:
const message = (messages as any)[id]; // no error
That gets rid of the error, but the inferred type of message
is any
.
There's another way:
const message = (messages)[id as keyof typeof messages]; // no error
Now the inferred type of message
is string
. Much better, but only because we're telling TypeScript "trust me, this is a valid key".
But... Are we sure it is valid?
The proper fix
We looked at the type of our id
, and it wasn't string
at all.
Remember that it was being obtained from some obscure logic.
const id = getMessageIdFromSomeObscureLogic();
It turned out that the type of id
was being inferred to a union type like this: 'success' | 'warning' | 'error' | 'example' | 'banana' | 'typescript' | 'javascript'
So this was already strongly typed. Why are we getting an error?
It turns the messages
object was missing the banana
key.
This was a bug! Caught by making the TypeScript configuration a little bit stricter.
Conclusion
Increasing the "strictness" of our TypeScript configuration can help us catch issues at compile time which otherwise would have happened live or (if we're lucky) in our tests.
Also, updating our TypeScript version can help a lot. For instance, the initial error we got with TypeScript 3.3 was:
Element implicitly has an 'any' type because type '{ success: string; warning: string; error: string; example: string; typescript: string; javascrip...' has no index signature.
But with TypeScript 3.5 it's a lot more helpful, especially the second paragraph where it mentions the 'banana'
property we were missing:
Element implicitly has an 'any' type because expression of type '"success" | "warning" | "error" | "example" | "typescript" | "javascript" | "banana"' can't be used to index type '{ success: string; warning: string; error: string; example: string; typescript: string; javascript: string; }'. Property 'banana' does not exist on type '{ success: string; warning: string; error: string; example: string; typescript: string; javascript: string; }'.
That would have saved us quite some time.
Photo by Pete Hardie on Unsplash
Top comments (5)
Awesome stuff, I use typescript every day for this precise reason, how it enables me to catch bugs in compile time. For the examples you used I would have used a string literal, making it impossible to forget a key in the messages object.
Hi! Thank you. This example is not literally the original code because I'm not allowed to share it.
Where do you suggest having a string literal?
I'd cast the return value of
getMessageIdFromSomeObscureLogic()
to a string literal like so:type messageTypes = "success" | "error" | "warning" | "bananas" | etc...
.And I'd type the messages object like so:
const messages: [key in messageTypes]: string;
Yes! that would work as well. And it results in a better error report:
messages
object declaration (where thebanana
property is missing) as opposed to where we try to access it by keymessages[id]
✅"Property 'bananas' is missing..."
even with TypeScript 2.4. ✅Love the article. Can't wait to see more typescript articles from you in the future