[no-unnecessary-condition] ignore array index return

[astorije]

Consider the following snippet:

const foo = ['a', 'b', 'c']; // type: string[]
const bar = foo[5]; // type: string, value: undefined

// Passes the rule
if (foo[5]) {
  console.log(foo[5]);
}

// Fails the rule
if (bar) {
  console.log(bar);
}

Thanks to @Retsam's work on #1534, the first example passes the linter, however as the author mentions in their PR, it doesn't handle less trivial cases, such as storing the value in a variable (which is very common when you want to use the value being tested in the body of the if).

I realize that supporting this (and other advanced) cases might be a lift. In the meantime, or alternatively, any thoughts on an option to entirely ignore arrays? In the current state, I don't believe there is a way to make the second example above pass the linter without disabling the rule or getting rid of the variable.
I believe such option was mentioned in #1544, for reference.

Versions

package	version
@typescript-eslint/eslint-plugin	2.24.0
@typescript-eslint/parser	2.24.0
TypeScript	3.8.3
ESLint	6.8.0
node	12.14.0
npm	6.13.4

[bradzacher]

It would not really be possible, no.

From the POV of typescript, a string is a string. Doesn't matter where it came from.
So for TS, there's no difference between const x = 'a' and const y = foo[5] - they both just have a string type.

Which means in order to detect this, the rule would have to do control-flow analysis of a variable to determine where the value in any variable has come from.
In some cases this might be simple to do, but it very, very quickly degrades into an intractable problem to solve (see some examples below).

There's but one case that's "easy" to solve, and that is a const variable whose value was directly assigned from an array index:

const bar = foo[5];
if (bar) {}

Happy to accept a PR if you want to support this case, otherwise I'd say that it's not possible to do.

---

const foo = ['a', 'b', 'c'];
const bar = foo[5];

if (bar) {} // "relatively" easy to detect, as there has been exactly one assignment.

let bam = foo[5];

bam = 'a';
if (bam) {} // hard to tell that if the value is an array

if (someCondition) { bam = 'a'; }
if (bam) {} // impossible to know if the value came from an array

const buz = foo[5];
const bang = buz;
if (bang) {} // really, really, really hard to know if the value came from an array

test(bar);
function test(baz: string) {
  if (baz) {} // impossible to detect
}
 

[astorije]

Thanks @bradzacher, yet another amazing piece of feedback, very helpful :)
It's very interesting to learn more about the dependence on the language, the limitation or capabilities of various things, etc.

In the examples above, this is also an acceptable alternative and satisfies the linter:

const foo = ['a', 'b', 'c']; // type: string[]

// Passes the rule
if (5 in foo) {
  console.log(foo[5]);
}

(Or course it's a little silly like this but imagine a dynamic index)

As we go through all our projects one by one, we'll see if other cases arise. Should the format described above come up too often, I'll see if I can look at improving the linter.

[astorije]

Following-up on this, it would also be great to be able to ignore Records as well. We are having the following case:

In our own code, we have something of the sort:

if (!client.getResolvers().Foo?.id) {
    client.addResolvers({
      Foo: {
        id: /* ... */,
      },
    });
}

client is controlled by a third-party library, which defines getResolvers() return type as:

[key: string]: {
  [field: string]: { /* ... */ };
};

In other parts of the code, we have been able to rewrite the value of the record as [field: string]: { /* ... */ } | undefined; but since this is a third-party dependency, we do not have this luxury here.

Because client.getResolvers().Foo is non-nullable type-wise, the rule flags the extra ? as unnecessary, which is not true.

I think having one or multiple options to ignore things like this, lookups that can be undefined even though TS typing indicates it is not, would make things safer, as following the linter recommendation breaks the code here. What do you think?

[bradzacher]

The problem is that that that option would add a lot of unsafety in the rule, as you'll no longer get warned about records within your control.
I don't think that makes it a good option.

A workaround is to inline the call and apply a custom type:

declare const client: {
    getResolvers(): Record<string, Record<string, number>>;
    addResolvers(resolver: Record<string, Record<string, number>>): void;
};

type SafeResolversRecord = Record<string, Record<string, number | undefined> | undefined>;

const resolvers: SafeResolversRecord = client.getResolvers();
if (resolvers.Foo?.id) {
    client.addResolvers({
        Foo: {
            id: 1,
        },
    });
}

depending on how the module defines its types, you could even augment this type into the module itself to make it easier to consume:

import "foo";
declare module "foo" {
  export type SafeResolversRecord = Record<string, Record<string, number | undefined> | undefined>;
}

////////

import { SafeResolversRecord } from 'foo';

[astorije]

That's really great advice, thank you @bradzacher!

[sindresorhus]

microsoft/TypeScript#13778 would fix this, right?

[bradzacher]

Yup! It would definitely fix this.
This is a problem for all index access in TS, and is a huge source of unsafety in codebases.
TBF - flow (which prioritises type soundness above all else) has this same problem. In this case, both systems just prioritise the devx over safety for this.

Because of #1534, we handle the trivial to detect case of if (arr[0]) {} (the rule detects that arr is an array type, and ignores the condition on it).
But it doesn't currently handle any more cases (like assigning to a variable).

We can use scope analysis to handle this case:

const x = arr[0];
if (x) {} // detectable

Any other cases mentioned in #1798 (comment) get very fuzzy and likely to false positive/negative.