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)

IMO this would benefit from a return type

This is a TS type error, so, not sure if we need the test. If we keep it let's add a comment that this is a type error, though.

Yes! I think it may still be valuable having such a test to make sure the rule doesn't report in addition to Typescript, making it extra noisy.

Do you think it's worth having these kind of tests? If we keep them, should I add a // @ts-expect-error above them (referencing #8298).

I think this is relevant for the other type errors (as they should all be under the valid cases to test the rule is not overly noisy).

I think that's a fine resolution to that, yeah 👍

type error

type error

type error

type error

type error

(testing)

I think let's add some test cases around generators as well? Like

function* generatorOfPromises() {
  yield Promise.resolve(1)
  yield Promise.resolve(2)
  yield Promise.resolve(3)
}

Promise.all(generatorOfPromises()); // should not report


function* generatorOfNumbers() {
  yield 1;
  yield 2;
  yield 3;
}

Promise.all(generatorOfNumbers()); // should report

and/or using the Generator<...> built-in type.

Also, ReadonlyArray and friends?

Also, array literals (most likely the primary way Promise.all() will be used:

Promise.all([Promise.resolve(1), 2, Promise.resolve(3)]);

Ideally this would be special-cased when the [] syntax is found and would report specifically on the 2 rather than on the whole array?

Yes! I didn't consider generators and friends, thanks for catching this!

Regarding array literals - Initially I was bit hesitant to special case reporting these as this can turn a single report (Promise.all(x)) to multiple reports (e.g. Promise.all([1, Promise.resolve(2), 3])). Though I don't think this would have a realistic auto-fix or suggestion, and I agree that reporting exactly where the issue is a lot better (especially since this pattern seem to be a very common one).

I adjusted the PR to special case array literals and added the relevant tests, thanks for commenting on this 🚀

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)