Undefined isn't always removed with check and noUncheckedIndexedAccess.

[fiddleplum]

Bug Report

🔎 Search Terms

noUncheckedIndexedAccess

🕗 Version & Regression Information

I don't know when this started, but I'm using TypeScript 5.0.2.

⏯ Playground Link

Playground Link

💻 Code

Using TypeScript 5.0.2 with noUncheckedIndexedAccess set to true.

const a: { [key: string]: string } = {};
const x: string = 'the pits' + '';

if (a[x] === undefined) {
	a[x] = '';
}
const b = a[x];

🙁 Actual behavior

The type of b is string | undefined, when it should be just string.

However, if you remove the + '' in the x = ... line, then b correctly shows string.

🙂 Expected behavior

I would expect b to always be reduced to string because a[x] is checked for undefined and assigned beforehand.

It seems odd that adding + '', or anything else really, seems to remove the ability to reduce b to a string in the subsequent commands, even though x is a string in both cases. It seems like there is some hidden typing information not shown.

[MartinJohns]

Duplicate of #10530. Type narrowing does not occur for indexed access forms e[k] where k is not a literal. Just store it in a local const variable.

It seems odd that adding + ''

Without this the type of x is inferred to be "the pits", a literal. By adding something to the string it's inferred to be string, not a literal anymore.

[fiddleplum]

Yeah it looks to be same cause, but that issue's original code has been fixed, whereas this is still happening in TypeScript 5.0.2, so it's not quite a duplicate. The fix to move it into a local const variable seems a bit like a workaround, rather than the proper way of doing things.

It would also be nice if TypeScript typing information actually showed that it was a literal, even though it says a more generic string as its type when you hover over it, which seems to be the hidden information I was guessing at.

[MartinJohns]

Yeah it looks to be same cause, but that issue's original code has been fixed

Yeah, it's kinda unfortunate, that issue was a catch all for indexed access narrowing. Numerous issues reporting the exact issue as yours have been closed as a duplicate of that one.

[fiddleplum]

Yeah, I agree. The last comment mentioned splitting some of the other cases up. I figure this is a super simple example and so might be helpful to keep this one open.

@RyanCavanaugh this isn't a duplicate of that issue, but if you have another issue that this is a duplicate of, then we could refer to that one, since it does seem that there are other cases that exist. It seems like the #10530 issue should be closed in deference to others since it already has a solution with a merged PR.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.