You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TypeScript shouldn't assume {[name: string]: NonUndefinedType} has no undefined properties #23817
This is a known issue and is unfortunately "as intended", see #9235, #13161, #12287, and #7140. It's the same reason why accessing arrays by index does not result in a possibly undefined type, even tho theoretically the array could be empty. You'd need to add security checks basically at every indexer and array access, which would add a lot of bloat code to cases where usually you know beforehand that you have a value.
A common practice is to leave it as it is when you know that you will always access known keys, or explicitly add undefined to your indexer type:
interfaceFoo{[_: string]: number|undefined;}
There's still an open proposal to add a compiler flag to automatically mark such indexers as undefined with an additional strict-flag: #13778
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
Activity
MartinJohns commentedon May 2, 2018
This is a known issue and is unfortunately "as intended", see #9235, #13161, #12287, and #7140. It's the same reason why accessing arrays by index does not result in a possibly undefined type, even tho theoretically the array could be empty. You'd need to add security checks basically at every indexer and array access, which would add a lot of bloat code to cases where usually you know beforehand that you have a value.
A common practice is to leave it as it is when you know that you will always access known keys, or explicitly add
undefinedto your indexer type:There's still an open proposal to add a compiler flag to automatically mark such indexers as
undefinedwith an additional strict-flag: #13778typescript-bot commentedon May 16, 2018
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.