The heuristics here seem to have minor edge case bugs.

interfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfNull:MyArray<Promise<void>,null>;declareconstarrayOfPromises:MyArray<null,Promise<void>>;Promise.all(arrayOfNull);// no report; should reportPromise.all(arrayOfPromises);// does report; shouldn't report

Note that if you switchinterface totype, 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 withchecker.isArrayLikeType() (which seems to check if the value is assignable toArray<any>).

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

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

  interfaceMyIterable<Unused,T>extendsIterable<T>{}declareconstx:MyIterable<Promise<void>,null>;// should report but doesn'tPromise.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 correctlydeclareconstx:Array<object>;`${x}`;// should report but doesn'tinterfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfObjects:MyArray<null,object>;`${arrayOfObjects}`;

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

    // normally reports correctlydeclareconstx:Array<Promise<void>>;x;// should report but doesn'tinterfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfPromises:MyArray<null,Promise<void>>;arrayOfPromises;

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

    // normally reports correctlydeclareconstx:Array<string>x.reduce((accum,name)=>({    ...accum,[name]:true,}),{}asRecord<string,boolean>,);// should report but doesn'tinterfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfStrings:MyArray<null,string>;arrayOfStrings.reduce((accum,name)=>({    ...accum,[name]:true,}),{}asRecord<string,boolean>,);

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

Edit: I think themain 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 withchecker.isArrayLikeType() (which seems to check if the value is assignable toArray<any>).
  Getting the type of the element(s) of the array seems to be a bit trickier, and may be possible through TypeScript's internalgetIterationTypesOfIterable or similar.
  Unless additional APIs are exposed, the best I've managed to come up with is usingchecker.isArrayLikeType() and getting the value of the array viaarrayType.getNumberIndexType(). This seems to work OK, though a similar case that extendsIterable still has this issue (playground link):

  interfaceMyIterable<Unused,T>extendsIterable<T>{}declareconstx:MyIterable<Promise<void>,null>;// should report but doesn'tPromise.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 correctlydeclareconstx:Array<object>;`${x}`;// should report but doesn'tinterfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfObjects: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 correctlydeclareconstx:Array<Promise<void>>;x;// should report but doesn'tinterfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfPromises:MyArray<null,Promise<void>>;arrayOfPromises;

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

  // normally reports correctlydeclareconstx:Array<string>x.reduce((accum,name)=>({    ...accum,[name]:true,}),{}asRecord<string,boolean>,);// should report but doesn'tinterfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfStrings:MyArray<null,string>;arrayOfStrings.reduce((accum,name)=>({    ...accum,[name]:true,}),{}asRecord<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 thegetIterationTypesOfIterable 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 themain 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 withchecker.isArrayLikeType() (which seems to check if the value is assignable toArray<any>).
  Getting the type of the element(s) of the array seems to be a bit trickier, and may be possible through TypeScript's internalgetIterationTypesOfIterable or similar.
  Unless additional APIs are exposed, the best I've managed to come up with is usingchecker.isArrayLikeType() and getting the value of the array viaarrayType.getNumberIndexType(). This seems to work OK, though a similar case that extendsIterable still has this issue (playground link):

  interfaceMyIterable<Unused,T>extendsIterable<T>{}declareconstx:MyIterable<Promise<void>,null>;// should report but doesn'tPromise.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 correctlydeclareconstx:Array<object>;`${x}`;// should report but doesn'tinterfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfObjects: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 correctlydeclareconstx:Array<Promise<void>>;x;// should report but doesn'tinterfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfPromises:MyArray<null,Promise<void>>;arrayOfPromises;

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

  // normally reports correctlydeclareconstx:Array<string>x.reduce((accum,name)=>({    ...accum,[name]:true,}),{}asRecord<string,boolean>,);// should report but doesn'tinterfaceMyArray<Unused,T>extendsArray<T>{};declareconstarrayOfStrings:MyArray<null,string>;arrayOfStrings.reduce((accum,name)=>({    ...accum,[name]:true,}),{}asRecord<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 thegetIterationTypesOfIterable 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 themain 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 soreturn null; seems correct as-is here rather than anullThrows() 👍

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 throwinglike is done here instead ofnullThrows()).