Narrowing for constant indexed access fails on array getter

[grant-d]

🔎 Search Terms

constant indexed access, array

🕗 Version & Regression Information

• This changed between versions 5.4.5 and 5.5.beta
• This changed in commit or PR

⏯ Playground Link

I could not repro this in playground, due to the lib import

💻 Code

import crypto from 'crypto-js'

const bar = "abc"
const foo: crypto.lib.WordArray = crypto.enc.Utf8.parse(bar) // Returns type: { words: number[], ... }
for (let i = 0; i < foo.words.length; i++) {
  foo.words[i] += 1
//~~~~~~~~~~~~ error TS2532: Object is possibly 'undefined'.

  // Alternatively:
  foo.words[i] = foo.words[i] + 1
//               ~~~~~~~~~~~~ <same error>
}

Adding suitable checks in the loop-body for falsey values does not fix it, eg:

if (foo && foo.words && foo.words[i]) {
 // Same code as above, same error
}

However the following does fix it:

const word = foo.words[i]
if (word) {
  foo.words[i] = word + 1 // OK
}

🙁 Actual behavior

error TS2532: Object is possibly 'undefined'.

🙂 Expected behavior

No error - this type-checked fine previously

Additional information about the issue

This issue is new since the new Control Flow Narrowing for Constant Indexed Accesses feature. Rolling back to the previous typescript version 'fixes' it

[Andarist]

You can often import npm packages in the playground just fine. It's capable of fetching their types.

I don't see any error here with the nightly version: TS playground. foo.words has number[] type so I'm not sure how undefined has crawled into all of this in your tests. Perhaps you are using noUncheckedIndexedAccess?

This would indeed show the difference in the behavior:
TS 5.4
TS nightly

This, in turn, looks like a correctness improvement.

[RyanCavanaugh]

If this is just an array, I don't see why you need crypto-js as part of the repro. Please provide a minimal example, with config, that shows what's happening

[grant-d]

@RyanCavanaugh yes I am aware of that, but I was unable to find a repro without the package.

@Andarist I think you nailed it - thanks so much, that must be the issue. Not sure what the action is here, I am closing but please re-open as necessary.

[grant-d]

@RyanCavanaugh here is a minimal repro in TS Playground (based on @Andarist example)

Including code here too for ease of tracking:

// @noUncheckedIndexedAccess: true
interface Foo { words: number[] }
const foo: Foo = { words: [1, 2, 3] }

for (let i = 0; i < foo.words.length; i++) {
  foo.words[i] += 1 // Alternative 1) Same error as below

  foo.words[i] = foo.words[i] + 1 // Alternative 2) Same error as below

  // Alternative 3) Explicit falsey check still fails
  if (foo.words[i]) {
    foo.words[i] = foo.words[i] + 1
    //             ^Object is possibly 'undefined'.(2532)^
  }
}

[Andarist]

The problem here is that i is assigned to so it doesn't pass this check:
https://github.com/microsoft/TypeScript/pull/57847/files#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R26613

i is special in loops. We know that it's only assigned to after this loop block. So perhaps some extra fine-tuning for this case would be possible.

[Andarist]

Oh, this just never works for variables that are reassigned:

function f1(obj: Record<string, unknown>) {
  let key: string = "";
  if (typeof obj[key] === "string") {
    obj[key].toUpperCase();
  }
  key = ""; // toggle to see the error to go away and come back
}

This is kinda spooky to see an error pop up on a previous line that seemingly has no real correlation with the line that just got added.

[grant-d]

Possibly related
#59185