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 🙂

I always appreciate how deeply you investigate things like this, and how clear the examples you come up with are 🙏

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}`;

I actually think this behavior is arguably correct here. It's only with a true built-in array that the .toString() behavior is known to subsequently call its elements' .toString()s, whereas other "array"s/arraylikes may have different stringification. So in this case, we're reasoning based on implementation details of built-in arrays.

• 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>,
  );

With these two... It's debatable IMO, and I could be convinced either way what the "correct" behavior is. We're linting for how these arraylikes quack, rather than the exact implementation details. Though (maybe?) an argument maybe could be made that the signature of .reduce() is an implementation detail rather than a general feature of arraylikes.

In any case I don't think there's a clear cut wrong behavior in any of these that warrants proactively filing issues (versus reacting to user feedback if anyone encounters these edge cases in the wild).

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

I think this current state looks great! I'd say this is a very good "best effort" approach at replicating the getIterationTypesOfIterable TS API (which really would be nice to have!), and we'll find out from user feedback if the remaining edge cases really are necessary to solve. Thanks for digging so deep into this.

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

Yep, should be fixed now! (after merging from main)

I always appreciate how deeply you investigate things like this, and how clear the examples you come up with are 🙏

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}`;

I actually think this behavior is arguably correct here. It's only with a true built-in array that the .toString() behavior is known to subsequently call its elements' .toString()s, whereas other "array"s/arraylikes may have different stringification. So in this case, we're reasoning based on implementation details of built-in arrays.

• 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>,
  );

With these two... It's debatable IMO, and I could be convinced either way what the "correct" behavior is. We're linting for how these arraylikes quack, rather than the exact implementation details. Though (maybe?) an argument maybe could be made that the signature of .reduce() is an implementation detail rather than a general feature of arraylikes.

In any case I don't think there's a clear cut wrong behavior in any of these that warrants proactively filing issues (versus reacting to user feedback if anyone encounters these edge cases in the wild).

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

I think this current state looks great! I'd say this is a very good "best effort" approach at replicating the getIterationTypesOfIterable TS API (which really would be nice to have!), and we'll find out from user feedback if the remaining edge cases really are necessary to solve. Thanks for digging so deep into this.

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

Yep, should be fixed now! (after merging from main)

(cov nit) this might also be unreachable? 🤷 But if so return null; seems correct as-is here rather than a nullThrows() 👍

Oh, I completely missed codcov, thanks! I've updated the PR with your suggestions. I'm not sure about this one though, it's hard to tell if it's truly unreachable or if there's a case I've missed.

I think this is OK either way (though I think this would require throwing like is done here instead of nullThrows()).