The heuristics here seem to have minor edge case bugs.

interface MyArray<Unused, T> extends Array<T> {};

declare const arrayOfNull: MyArray<Promise<void>, null>;
declare const arrayOfPromises: MyArray<null, Promise<void>>;

Promise.all(arrayOfNull); // no report; should report
Promise.all(arrayOfPromises); // does report; shouldn't report

Note that if you switch interface to type, this works correctly 🧐

Interesting! I didn't consider this edge case!

I took some time trying to figure this out, here are my thoughts:

• checker.isArrayType() doesn't flag this type as array, and I've only managed to compare this kind of value is with checker.isArrayLikeType() (which seems to check if the value is assignable to Array<any>).

  Getting the type of the element(s) of the array seems to be a bit trickier, and may be possible through TypeScript's internal getIterationTypesOfIterable or similar.

  Unless additional APIs are exposed, the best I've managed to come up with is using checker.isArrayLikeType() and getting the value of the array via arrayType.getNumberIndexType(). This seems to work OK, though a similar case that extends Iterable still has this issue (playground link):

  interface MyIterable<Unused, T> extends Iterable<T> { }
  declare const x: MyIterable<Promise<void>, null>;
  
  // should report but doesn't
  Promise.all(x);

• This issue seems to affect additional rules, I was able to create these reproducible ones (should I open issues for them? I'm not sure how often this case gets used in the wild):

  • no-base-to-string (link to playground):

    // normally reports correctly
    declare const x: Array<object>;
    `${x}`;
    
    // should report but doesn't
    interface MyArray<Unused, T> extends Array<T> { };
    declare const arrayOfObjects: MyArray<null, object>;
    
    `${arrayOfObjects}`;

  • no-floating-promises (link to playground):

    // normally reports correctly
    declare const x: Array<Promise<void>>;
    x;
    
    // should report but doesn't
    interface MyArray<Unused, T> extends Array<T> { };
    declare const arrayOfPromises: MyArray<null, Promise<void>>;
    
    arrayOfPromises;

  • prefer-reduce-type-parameter (link to playground):

    // normally reports correctly
    declare const x: Array<string>
    
    x.reduce(
      (accum, name) => ({
        ...accum,
        [name]: true,
      }),
      {} as Record<string, boolean>,
    );
    
    // should report but doesn't
    interface MyArray<Unused, T> extends Array<T> { };
    
    declare const arrayOfStrings: MyArray<null, string>;
    
    arrayOfStrings.reduce(
      (accum, name) => ({
        ...accum,
        [name]: true,
      }),
      {} as Record<string, boolean>,
    );

• I updated the PR with the changes described above, would love to hear your thoughts.

Edit: I think the main branch has failing tests which cause this PR to be red too.

Hey! I'm going to be away from a computer until beginning of August. I can look at it then, or feel free to move this along in the meantime 🙂

Noting that there was talk on the issue of adding an option for .some() vs .every() semantics for whether to report things like Promise.all([2, Promise.resolve(3)]).

I think the .some() semantics used here are good and if someone wants the .every() semantics option after it's released we can entertain that as a followup, but no need for this version.