TypeScript doesn't have any real way to track the identity of an unknown but constant string in the type system. You can make the compiler too loose or too strict, but accuracy is not possible.
If you know the literal type of a string like const key = "a", then you can say that an object has a type like declare const obj: Record<typeof key, number> and it will evaluate to {a: string} which has a specific known property at the key key. You can evaluate obj[key] and know that you're getting a number, and if you try to evaluate obj[otherKey] for some other random key string otherKey, the compiler will catch that as a mistake:
const key = "a";
const obj: Record<typeof key, number> = { [key]: Math.PI };
const otherKey = getRandomString();
obj[key].toFixed(2); // okay
obj[otherKey].toFixed(2); // error!
// Expression of type 'string' can't be used to index type 'Record<"a", number>'.
But if all you know is that it's a string, like const key = getRandomString(), there's no way to encode that an object obj has a known property at the key key without saying the same thing about every string-valued key. That is, declare const obj: Record<typeof key, number> evaluates to {[k: string]: number}, with a string index signature. You can evaluate obj[key], but the compiler cannot tell that apart from obj[otherKey]. By default, the compiler will just let you do both without complaint and pretend that the outcome is number, even though the latter will almost certainly result in undefined and runtime errors aren't far behind:
const key = getRandomString();
const obj: Record<typeof key, number> = { [key]: Math.PI };
const otherKey = getRandomString();
obj[key].toFixed(2); // okay
obj[otherKey].toFixed(2); // okay, but very likely RUNTIME ERROR!
For a while this was about as good as it got, but there were many requests for protection against this sort of mistake. And eventually it was implemented: TypeScript 4.1 introduced the --noUncheckedIndexedAccess compiler option, which, when enabled, adds undefined to the domain of values read from (but not written to) index signatures. But if you enable it, now you get the opposite problem:
const key = getRandomString();
const obj: Record<typeof key, number> = { [key]: Math.PI };
const otherKey = getRandomString();
obj[key].toFixed(2); // error, object is possibly undefined
obj[otherKey].toFixed(2); // error, object is possibly undefined
Even obj[key] is considered to be possibly undefined. So instead of a false negative where unsafe code is permitted, you get a false positive where safe code is prohibited. The compiler still has no idea that key is safe and otherKey is unsafe. They're both just of type string. The compiler only sees their types, not their identities.
Indeed this inability to tell the difference between safe and unsafe indexes is why --noUncheckedIndexedAccess is not included in the "standard" --strict suite of compiler options. Doing so would cause a lot of perfectly safe real-world code to start producing errors, a big breaking change. And if everyone began seeing this error all over the place, many would decide to use non-null assertions (!) to suppress it, and eventually just do so out of habit, which completely defeats the purpose of the flag in the first place.
The flag is there for those who want it. If you think the benefits of using it outweigh the disadvantages, you should feel free to enable it, but if it annoys you, you should leave it off. Either way, you'll need to inspect index signature property reads yourself and decide whether they are safe or unsafe, since the compiler unfortunately cannot.
Playground link to code
